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

[Andres Lagar-Cavilla <andreslc@xxxxxxxxxxxxxx>]

> 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.
> 
> Joe

Well, there is more than that. Does Xen-access capture foreign writable 
mappings via grants and dom0 map_foreign_bulk and friends?

Aravindh, I thought of a solution to your problem. It seems the ring collapses 
under recursive identical faults. If they are all the same, you can merge them 
up. It's relatively simple and robust logic to compare against the last 
un-consumed element in the ring

1. read last unconsumed
2. compare
3. different? write into ring
4. same? atomic_read consumer index to ensure still unconsumed
5. consumed? write into ring
<still a possible race below, but not a tragedy>
6. not consumed? drop…

Kind of like what remote display protocols do quite aggressively. More 
aggressive batching and reordering is hard with a consumer as decoupled as in 
the Xen shared rings case. I'm pretty hopeful this will solve this one problem.

But am not sure how to solve the very general problem of aggressive overflow in 
a scheduling context that does not allow exiting to schedule() and thus wait().

Andres
> 
> 
> 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?
>> 
>> Jan
>> 
>> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel