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

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


Best regards,
Yang



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