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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 04.08.14 at 07:05, <wei.ye@intel.com> wrote:

> 
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Monday, July 28, 2014 4:25 PM
>> To: Ye, Wei
>> Cc: ian.campbell@citrix.com; Paul.Durrant@citrix.com;
>> ian.jackson@eu.citrix.com; stefano.stabellini@eu.citrix.com; xen-
>> devel@lists.xen.org; keir@xen.org 
>> Subject: Re: [PATCH v1 0/2] Extend ioreq-server to support page write
>> protection
>> 
>> >>> On 28.07.14 at 19:55, <wei.ye@intel.com> 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?

Jan