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

[Tim Deegan <tim@xxxxxxx>]

At 17:49 +0000 on 14 Aug (1408034941), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:tim@xxxxxxx]
> > > Could we introduce a cpu-write-protection attribute only for functional
> > > usages which don't care about DMA path like in XenGT?
> > 
> > Possibly.  Sorry for going over things that have probably already been
> > covered but AIUI you are saying that XenGT needs to allow full DMA access
> > to this memory area but only read-only CPU access.  If that's what's
> > needed then I think a new type with these semantics is the best way of
> > doing it (and requiring no shared IOMMU/HAP tables).  But:
> 
> It's about GPU page table write-protection, so XenGT needs to trap
> writes in both CPU/DMA paths:
> 
> * CPU writes are captured by read-only permission in EPT
> * GPU writes are captured by scanning GPU commands before they're
> submitted for execution, as part of the 'mediation' concept in XenGT
> mediated pass-through architecture.
> 
> Note XenGT doesn't use IOMMU because w/o SR-IOV a single device
> entry can't be used to server multiple VMs.

Oh, I see.  So you don't actually want the GPUPTs mapped for DMA at
all.  That's much easier.

> So XenGT can achieve true 'write-protection' w/o IOMMU restarting
> fault support. However it's very GPU specific. As a general implementation, 
> I think a new type with below semantics should be enough:
> 
> - only CPU access to the protected area, so it's removed from IOMMU
> page table
> - require IOMMU/HAP seperate

I think we might want to make those tables separate in general.  IIRC we
were discussing that in another thread already.  But that aside, I think
a plain read-only mapping will DTRT for you -- it allows read-only DMA
from the GPUPTs, but that's no worse that the read-only CPU mapping.

After that, the only odd behaviour is that you're emulating writes to
read-only memory.  And that's where the new type is helpful: to say
that we should be emulating writes rather than dropping them.

> How would you call such a new type then? just p2m_write_protection
> or p2m_cpu_write_protection? (still need to differentiate write-protection
> from read-only, since the latter implies no writes)

p2m_mmio_write_dm?

Now that (I hope) I understand better what you need, I can see how
just using plain mmio_dm and emulating reads would be a plausible
solution too.  So I think I'd be happy with either that or a new type.

Cheers,

Tim.

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