Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Friday, December 12, 2014 6:54 PM
> 
> >>> On 12.12.14 at 08:24, <kevin.tian@xxxxxxxxx> wrote:
> > - is there existing _map_ call for this purpose per your knowledge, or
> > a new one is required? If the latter, what's the additional logic to be
> > implemented there?
> 
> I think the answer to this depends on whether you want to use
> grants. The goal of using the native driver in the guest (mentioned
> further down) speaks against this, in which case I don't think we
> have an existing interface.

yes, grants don't apply here. 

> 
> > - when you say _map_, do you expect this mapped into dom0's virtual
> > address space, or just guest physical space?
> 
> Iiuc you don't care about the memory to be visible to the CPU, all
> you need is it being translated by the IOMMU. In which case the
> input address space for the IOMMU (which is different between PV
> and PVH) is where this needs to be mapped into.

it should be in p2m level, not just in IOMMU. otherwise I'm wondering 
there'll be tricky issues ahead due to inconsistent mapping between EPT 
and IOMMU page table (though a specific attributes like r/w may be 
different from previous split table discussion). 

another reason here. If we just talk about shadow GPU page table, yes
it's used by device only so IOMMU mapping is enough. However we do 
have several other places where we need to map and access guest memory,
e.g. scanning command in a buffer mapped through GPU page table (
currently through remap_domain_mfn_range_in_kernel). 

> 
> > - how is BFN or unused address (what do you mean by address here?)
> > allocated? does it need present in guest physical memory at boot time,
> > or just finding some holes?
> 
> Fitting this into holes should be fine.

this is an interesting open to be further discussed. Here we need consider 
the extreme case, i.e. a 64bit GPU page table can legitimately use up all 
the system memory allocates to that VM, and considering dozens of VMs, 
it means we need reserve a very large hole. 

I once remember some similar cases requiring grabbing some unmapped
pfns (in grant table?). So wonder whether there's already a clean interface
for such purpose, or we need tweak a new one to allocate unmapped pfns
(but won't conflict with usages like memory hotplug)...

appreciate any suggestion here.

> 
> > - graphics memory size could be large. starting from BDW, there'll
> > be 64bit page table format. Do you see any limitation here on finding
> > BFN or address?
> 
> I don't think this concern differs much for the different models: As long
> as you don't want the same underlying memory to be accessible by
> more than one guest, the address space requirements ought to be the
> same.

See above.

Thanks
Kevin

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