On Mon, 4 Jan 2016 21:17:31 +0100 Laszlo Ersek <lersek@xxxxxxxxxx> wrote: > Michael CC'd me on the grandparent of the email below. I'll try to add > my thoughts in a single go, with regard to OVMF. > > On 12/30/15 20:52, Michael S. Tsirkin wrote: > > On Wed, Dec 30, 2015 at 04:55:54PM +0100, Igor Mammedov wrote: > >> On Mon, 28 Dec 2015 14:50:15 +0200 > >> "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > >> > >>> On Mon, Dec 28, 2015 at 10:39:04AM +0800, Xiao Guangrong wrote: > >>>> > >>>> Hi Michael, Paolo, > >>>> > >>>> Now it is the time to return to the challenge that how to reserve guest > >>>> physical region internally used by ACPI. > >>>> > >>>> Igor suggested that: > >>>> | An alternative place to allocate reserve from could be high memory. > >>>> | For pc we have "reserved-memory-end" which currently makes sure > >>>> | that hotpluggable memory range isn't used by firmware > >>>> (https://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg00926.html) > > OVMF has no support for the "reserved-memory-end" fw_cfg file. The > reason is that nobody wrote that patch, nor asked for the patch to be > written. (Not implying that just requesting the patch would be > sufficient for the patch to be written.) Hijacking this part of thread to check if OVMF would work with memory-hotplug and if it needs "reserved-memory-end" support at all. How OVMF determines which GPA ranges to use for initializing PCI BARs at boot time, more specifically 64-bit BARs. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
