[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 0/2] map grant refs at pfn = mfn



On Thu, 24 Jul 2014, Tim Deegan wrote:
> At 18:18 +0100 on 23 Jul (1406135907), Stefano Stabellini wrote:
> > Hi all,
> > this patch series introduces a second p2m mapping of grant reference on
> > ARM at guest physical address == machine address of the grant ref.  It
> > is safe because dom0 is already mapped 1:1. We export
> > XENFEAT_grant_map_identity to signal the guest that this second p2m
> > mapping is
> > available.
> > 
> > One reason for wanting the second p2m mapping is to avoid tracking mfn
> > to pfn mappings in the guest kernel. Since the same mfn can be granted
> > multiple times to the backend, finding the right pfn corresponding to a
> > given mfn can be difficult and expensive. Providing a second mapping at
> > a known address allow the kernel to access the page without knowing the
> > pfn.
> 
> Hrmn.  If your guest-kernel code relies on this new flag, you're 
> effectively requiring that driver domains and middlebox VMs be
> built 1:1 as well.  Unless they can deal with having a heavily
> fragmented memory map that's going to be a problem.
> 
> Also it prevents dom0 mapping anything else into its p2m.  Unless dom0
> knows where all the RAM in the system is (which is really none of its
> business) it can't be sure that a GFN is safe to use for the _first_
> p2m mapping, or any other p2m tricks it might like to play.

Wait, this flag is only necessary when no SMMU is available. Or when at
least one DMA-capable device is not protected by an SMMU.
In this configuration, we cannot do driver domains and we are forced to
have the 1:1 in Dom0 and track p2m info for foreign grants in dom0.

On the other hand if all the DMA-capable devices are protected by an
SMMU, then we don't need the 1:1, we don't need this flags, we can have
driver domains, we don't have to track the p2m for foreign grants in
dom0.

Julien has a patch series to tell Dom0 whether it can rely on the SMMU
and therefore avoid p2m tracking and swiotlb-xen. If this "xen_dma_safe"
flag is present, dom0 would avoid the swiotlb-xen altogether, and
XENFEAT_grant_map_identity would be useless.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.