Re: [Xen-devel] [PATCH v4 4/7] xen, common: add the XEN_DOMCTL_memory_mapping hypercall

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Wed, 2014-04-02 at 11:06 +0100, Jan Beulich wrote:
> >>> On 02.04.14 at 11:43, <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > This interface is already pretty broken for the case where a toolstack
> > maps the same mfns into a guest twice. But that is a pretty broken thing
> > for a toolstack to do.
> 
> Is it? In the context of the VGA ROM issue in qemu (discussed recently)
> it seemed reasonable to me to map this at both the PCI BAR specified
> location and the legacy ISA C0000h one.

That's emulated though isn't it? This interface is about real machine
iomem pages.

Anyway, the issue is that the permission is not reference counted so you
can do:
        map mfn 0x12345 at gfn 0xc0000
        map mfn 0x12345 at gfn 0xf0000000
        unmap mfn 0x12345 from 0xf0000000
        
Now the guest no longer has permission (as in iomem_access_permitted) to
access mfn 0x12345 but it still has a mapping at gfn 0xc0000 and can use
it (unless perhaps some iommu stuff goes on which I haven't grokked).

Perhaps we don't care about that and expect the toolstack/device model
to ensure that it unmaps everything or nothing. (I didn't check if a
subsequent unmap from 0xc0000 would work BTW).

If we do care about this issue then our choices are:
      * Implement proper referencing counting of iomem permissions
        (tricky?)
      * Force the reference counting to be trivial by requiring that the
        reference is at most 1
      * Split the manipulation of iomem permissions out of
        XEN_DOMCTL_memory_mapping and require the toolstack to issue
        XEN_DOMCTL_iomem_permission first (and last after all mappings
        are removed).
      * Do some sort of exhaustive search on unmap like Julien suggested
      * ???

Ian.


> Similar considerations might
> apply to other PCI option ROMs needed for booting (PXE comes to mind).



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