Re: [Xen-devel] [PATCH v1 0/2] Extend ioreq-server to support page write protection

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Tian, Kevin wrote on 2014-08-05:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Tuesday, August 05, 2014 12:52 AM
>> 
>>>>> On 05.08.14 at 09:35, <yang.z.zhang@xxxxxxxxx> wrote: Tian, Kevin
>>>>> wrote on 2014-08-05: From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>>>>> Sent: Monday, August 04, 2014 12:35 AM
>>>>> 
>>>>>>>> On 04.08.14 at 07:05, <wei.ye@xxxxxxxxx> wrote:
>>>>> 
>>>>>> 
>>>>>> Jan Beulich wrote on 2014-07-28:
>>>>>>> devel@xxxxxxxxxxxxx; keir@xxxxxxx
>>>>>>> Subject: Re: [PATCH v1 0/2] Extend ioreq-server to support
>>>>>>> page write protection
>>>>>>> 
>>>>>>>>>> On 28.07.14 at 19:55, <wei.ye@xxxxxxxxx> wrote:
>>>>>>>> ioreq-server is proposed to forward PIO and MMIO request to
>>>>>>>> multiple device models according to the io range. XenGT
>>>>>>>> (Intel Graphics Virtualization technology, please refer to
>>>>>>>> https://01.org/xen/blogs/srclarkx/2013/graphics-virtualizatio
>>>>>>>> n-
>>>>>>>> xengt) driver reside in Dom0 as a virtual graphics device
>>>>>>>> model also need to trap and emulate the guest's write
>>>>>>>> operation to some specific memory pages, like the memory
>>>>>>>> pages used by guest graphics driver as PPGTT(per-process graphics 
>>>>>>>> translation table).
>>>>>>>> We add an new p2m type "p2m_ram_wp" to trap the page write
>>>>>>>> operation. Page of this new p2m type is read only and for
>>>>>>>> write, the request will go to device model via ioreq-server.
>>>>>>> 
>>>>>>> So how is this write-protection supposed to work on the IOMMU
>>>>>>> side when sharing page tables?
>>>>>> 
>>>>>> Thanks for pointing out this question. Write-protection is not
>>>>>> supposed to work when sharing page tables between EPT and vt-d.
>>>>>> An explicit command line "iommu=no-sharept" should be setted
>>>>>> for avoiding undesirable iommu fault.
>>>>> 
>>>>> Requiring the unconditional use of a specific command line
>>>>> option is certainly fine for experimental code, but not beyond that.
>>>>> Behavior should be correct by default in production code.
>>>>> 
>>>>> But what's worse here: The option _allows_ device side writes
>>>>> from the guest. Why would device side writes be okay, but CPU side ones 
>>>>> not?
>>>>> 
>>>> 
>>>> right, whether ept is shared or not doesn't address the concern here.
>>>> In both cases we need maintain the same p2m view between CPU and
>>>> device side, otherwise it's broken...
>>>> 
>>>> One option is to treat wp similar to logdirty, i.e. exclusive to
>>>> VT-d device assignment, until in the future VT-d supports page
>>>> fault. We can provide a boot option to override the default
>>>> policy if user thinks OK.
>>>> 
>>>> 2nd option, like Wei mentioned in another mail, is to treat such
>>>> write protected PPGTT page tables as MMIO. new hypercall is
>>>> required to change the p2m type between p2m_io and p2m_ram, based
>>>> on allocation/free of guest page table. This way may impact
>>>> performance on read though.
>>>> 
>>>> Comments?
>>> 
>>> Another solution is using the EPT misconfiguration mechanism like
>>> what Xen does for MTRR emulation currently.
>> 
>> That would cause faults on reads as well, making it necessary to
>> emulate them.
>> 
> 
> Then it's same effect of p2m_mmio_dm.

p2m_mmio_dm will break VT-d but EPT misconfiguration doesn't.

> 
> Thanks
> Kevin


Best regards,
Yang


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