Re: [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> 
> > The question is why IOREQ_TYPE_COPY -> IOREQ_TYPE_PCI_CONFIG
> > translation is a must have thing at all? It won't make handling simpler.
> > For current QEMU implementation IOREQ_TYPE_COPY (MMIO accesses for
> > MMCONFIG) would be preferable as it allows to use the existing code.
> 
> Granted it's likely easier to implement, but it's also incorrect. You
> seem to have in mind the picture of a single IOREQ server (QEMU)
> handling all the devices.
> 
> Although this is the most common scenario, it's not the only one
> supported by Xen. Your proposed solution breaks the usage of multiple
> IOREQ servers as PCI device emulators.
> 

Indeed it will, and that is not acceptable even in the short term.

> > I think it will be safe to use MMCONFIG emulation on MMIO level for now
> > and later extend it with 'set_mmconfig_' dmop/hypercall for the
> > 'multiple device emulators' IOREQ_TYPE_COPY routing to work same as for
> > PCI conf, so it can be used by XenGT etc on Q35 as well.
> 

Introducing known breakage is not really on, particularly when it can be avoided with a reasonable amount of extra work.

  Paul

> I'm afraid this kind of issues would have been fairly easier to
> identify if a design document for this feature was sent to the list
> prior to it's implementation.
> 
> Regarding whether to accept something like this, I'm not really in
> favor, but IMO it depends on how much new code is added to handle this
> incorrect usage that would then go away (or would have to be changed)
> in order to handle the proper implementation.
> 
> Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel