> -----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
