qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 1/1] KVM: s390: Add MEMOP ioctl for reading/


From: Christian Borntraeger
Subject: Re: [Qemu-devel] [PATCH RFC 1/1] KVM: s390: Add MEMOP ioctl for reading/writing guest memory
Date: Wed, 04 Feb 2015 13:16:53 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Am 04.02.2015 um 12:42 schrieb Paolo Bonzini:
> 
> 
> On 04/02/2015 12:25, Christian Borntraeger wrote:
>> Whenever vhost or qemu or a finished aio request wrote content into a
>> virtio buffer, the HW has set the storage key for that physical page,
>> which  makes it automatically dirty/referenced in the guest visible
>> storage key. 
> 
> Ah, I knew the storage keys were per-physical page, but I wasn't sure if
> they were separate for the host and the guest.  That's obvious now.

Just something on top:
the storage key is per physical page. Just once. It contains C/R/ACC/F
(change, reference, access key, fetch protection)

But: there is also the pgste page table extension. That is used to  separate
both by doing logically ORs. The host and millicode will do the right shifting
copying  to keep both values separate, but when the physical storage key gets
dirty, the host and the guest view is now "changed==yes"

> 
> Can we detect non-zero storage key in emulated zPCI requests, and fail
> the request somehow?

Not right now. Even the kernel KVM module does not do this for emulated
instructions (as Linux has always key 0). Somewhen we might want to add
that capability, but its obviously not trivial for I/O like things. It
would get easier if we avoid VFIO etc and just had used the hardware support,
though. but as far as I can see this is not an option in QEMU.



Christian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]