On 02/08/2016 21:22, Emilio G. Cota wrote:
> An alternative is to have a separate lock for safe work, and check for
> safe work once there are no other locks held; a good place to do this is
> at the beginning of cpu_loop_exec. This scales better, and I'd argue
> it's simpler. In fact, I posted a
Hi Tianyou,
I see that you were trying to persist RAM in Qemu to a file.
http://marc.info/?l=qemu-devel&m=146134037011022&w=2
Could you share this work with me? I looked for it but couldn’t find it.
I tried -mem-path= but the file contents are always all 0’s. I tried
hacking qemu to mmap the fil
vq->avail.idx and vq->avail->ring[] are a 16bit values,
so read and write them with readw()/writew() instead of
readl()/writel().
To read/write a 16bit value with a 32bit accessor works fine
on little-endian CPU but not on big endian CPU.
Signed-off-by: Laurent Vivier
---
v2: vq->avail->ring[] i
The XTS cipher mode needs to be used with a cipher which has
a block size of 16 bytes. If a mis-matching block size is used,
the code will either corrupt memory beyond the IV array, or
not fully encrypt/decrypt the IV.
This fixes a memory corruption crash when attempting to use
cast5-128 with xts,
vq->avail is a 16bit value, so read and write it with
readw()/writew() instead of readl()/writel().
To read/write a 16bit value with a 32bit accessor works fine
on little-endian CPU but not on big endian CPU.
Signed-off-by: Laurent Vivier
---
tests/libqos/virtio.c | 4 ++--
1 file changed, 2 in
Hi, I'd appreciate a sense check on my expectations with TPM passthrough.
My goal is to use Windows Bitlocker and my TPM in a kvm/qemu guest. Is the
TPM passthrough implementation in qemu for this purpose and similar or have
I misunderstood?
Regards,
Kelvin
