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

["Ye, Wei" <wei.ye@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, August 5, 2014 3:52 PM
> To: Tian, Kevin; Ye, Wei; Zhang, Yang Z
> Cc: ian.campbell@xxxxxxxxxx; Paul.Durrant@xxxxxxxxxx;
> ian.jackson@xxxxxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx; Lv, Zhiyuan;
> xen-devel@xxxxxxxxxxxxx; keir@xxxxxxx; tim@xxxxxxx
> Subject: RE: [Xen-devel] [PATCH v1 0/2] Extend ioreq-server to support page
> write protection
> 
> >>> 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.

In our usage case, the read access is much less than write (zero read in Linux 
guest and 1/4 for read access compared to write in windows guest). 

> 
> Jan


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