Re: [Xen-devel] QEMU e820 Reservation (FW_CFG_E820_TABLE and fw_cfg etc/e820)
Stefano, Many thanks for responding to this. Resplies inline below. On 2015-03-04 10:11, Stefano Stabellini wrote: On Tue, 3 Mar 2015, Gordan Bobic wrote: Hi, I've been looking into custom e820 maps for domUs again, and found that functionality to provide QEMU with hints regarding e820 mapping has been upstream since some time in 2010 (FW_CFG_E820_TABLE) with more finely grained control (usable rather than just reserved entries) upstream since 2013 (fw_cfg etc/e820). The respective patches are here: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00996.html http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg00593.html What I have not been able to find is any documentation at all on how this e820 data can be given to QEMU when starting a domain. I can see from the structs in the patches how the data is packed for the relevant code to consume, but I cannot figure out what is the delivery vector for this data. How can I get QEMU to ingest the hints about any additional reserved e820 blocks? For context, I need this to work around IOMMU implementation bugs and mark areas of address space as reserved so that the guest doesn't trample over the host's PCI I/O ranges (which IOMMU should intercept, but being buggy, it doesn't). Many thanks in advance. Hello Gordan, FW_CFG_E820_TABLE is a special interface between SeaBios and QEMU but is not used on Xen. I guess it could be made to work on Xen, but I am pretty sure it doesn't at the moment. So this cannot be used to side-load an additional list of e820 reserved memory blocks at domU startup time? I think you would probably want to look at hvmloader instead: tools/firmware/hvmloader/e820.c. Yes, this is what I was looking at last time. I was just hoping that either of the above mentioned patches could be used to adjust the e820 map in a soft way rather hard-coding any changes into hvmloader/e820.c The latter is what I did last time, but it is extremely ugly and non-generic. And given the two interfaces I mentioned above it seems really wrong to be implementing a whole new method for manually loading an explicit e820 map. Is that not what the etc/e820 interface is already supposed to do? Gordan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] QEMU e820 Reservation (FW_CFG_E820_TABLE and fw_cfg etc/e820)
On 2015-03-04 10:33, Stefano Stabellini wrote: On Wed, 4 Mar 2015, Gordan Bobic wrote: Stefano, Many thanks for responding to this. Resplies inline below. On 2015-03-04 10:11, Stefano Stabellini wrote: On Tue, 3 Mar 2015, Gordan Bobic wrote: Hi, I've been looking into custom e820 maps for domUs again, and found that functionality to provide QEMU with hints regarding e820 mapping has been upstream since some time in 2010 (FW_CFG_E820_TABLE) with more finely grained control (usable rather than just reserved entries) upstream since 2013 (fw_cfg etc/e820). The respective patches are here: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00996.html http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg00593.html What I have not been able to find is any documentation at all on how this e820 data can be given to QEMU when starting a domain. I can see from the structs in the patches how the data is packed for the relevant code to consume, but I cannot figure out what is the delivery vector for this data. How can I get QEMU to ingest the hints about any additional reserved e820 blocks? For context, I need this to work around IOMMU implementation bugs and mark areas of address space as reserved so that the guest doesn't trample over the host's PCI I/O ranges (which IOMMU should intercept, but being buggy, it doesn't). Many thanks in advance. Hello Gordan, FW_CFG_E820_TABLE is a special interface between SeaBios and QEMU but is not used on Xen. I guess it could be made to work on Xen, but I am pretty sure it doesn't at the moment. So this cannot be used to side-load an additional list of e820 reserved memory blocks at domU startup time? Nope. Enabling the usage of FW_CFG_E820_TABLE on Xen is conceivable and once done you would be able to use it, but today it would not work. I think you would probably want to look at hvmloader instead: tools/firmware/hvmloader/e820.c. Yes, this is what I was looking at last time. I was just hoping that either of the above mentioned patches could be used to adjust the e820 map in a soft way rather hard-coding any changes into hvmloader/e820.c The latter is what I did last time, but it is extremely ugly and non-generic. I see. And given the two interfaces I mentioned above it seems really wrong to be implementing a whole new method for manually loading an explicit e820 map. Is that not what the etc/e820 interface is already supposed to do? I don't follow you here: what is the etc/e820 interface? See the 2nd patch I mentioned above, which supposedly adds etc/e820 fw_cfg file (whatever that means). Gordan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] QEMU e820 Reservation (FW_CFG_E820_TABLE and fw_cfg etc/e820)
Hi, I've been looking into custom e820 maps for domUs again, and found that functionality to provide QEMU with hints regarding e820 mapping has been upstream since some time in 2010 (FW_CFG_E820_TABLE) with more finely grained control (usable rather than just reserved entries) upstream since 2013 (fw_cfg etc/e820). The respective patches are here: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00996.html http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg00593.html What I have not been able to find is any documentation at all on how this e820 data can be given to QEMU when starting a domain. I can see from the structs in the patches how the data is packed for the relevant code to consume, but I cannot figure out what is the delivery vector for this data. How can I get QEMU to ingest the hints about any additional reserved e820 blocks? For context, I need this to work around IOMMU implementation bugs and mark areas of address space as reserved so that the guest doesn't trample over the host's PCI I/O ranges (which IOMMU should intercept, but being buggy, it doesn't). Many thanks in advance. Gordan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
