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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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