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

Re: [Xen-devel] Issue policing writes from Xen to PV domain memory

Hi Jan,

It's a good question. Capturing Xen-initiated access would be good for some use cases, but I had thought of that as a future enhancement.


On Wed, May 7, 2014 at 11:26 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>> On 07.05.14 at 21:37, <aravindp@xxxxxxxxx> wrote:
> I dug in further to figure out if there is any difference between HVM and PV
> domains with policing writes emanating from Xen. I started with how the
> runstate area in the guest is updated. It is done using __copy_to_guest().
> Here is the flow for PV and HVM.
> For PV:
> __copy_to_guest -> __copy_to_guest_offset -> __raw_copy_to_guest
> I think in the above scenario, the page permissions that are present in the
> shadow are adhered to for PV domains running with shadow and hence faults can
> occur.
> For HVM:
> __copy_to_guest -> __copy_to_guest_offset -> __raw_copy_to_guest ->
> copy_to_user_hvm -> hvm_copy_to_guest_virt_nofault Â-> __hvm_copy(flags =
> HVMCOPY_to_guest | HVMCOPY_no_fault | HVMCOPY_virt)
> If I look in __hvm_copy(), I see that access permissions are not adhered to.
> Writes to guest memory will go through even if the p2m_access type for that
> page has it set as non-writable. ÂSo it seems that we do not police writes to
> guest memory that emanate from Xen even for the HVM case. Is my reading of
> the code correct?

It would seem so, but the question (including whether actual behavior
matches intentions) really ought to be answered by the original author
of the code - let's see if he's still around under his email address from
back then... Joe?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.