Hi,
So maybe design that with memory hotplug in mind? Such as adding a new
qemu-specific type QEMU_RAM_HOTPLUG? Which seabios could use to reserve
the memory (but not add it to the e820 table for the guest)?
It will do job too. But extending semantics of standard table would be
On Mon, 04 Nov 2013 13:48:03 +0100
Gerd Hoffmann kra...@redhat.com wrote:
Hi,
So maybe design that with memory hotplug in mind? Such as adding a new
qemu-specific type QEMU_RAM_HOTPLUG? Which seabios could use to reserve
the memory (but not add it to the e820 table for the guest)?
On Mo, 2013-11-04 at 15:35 +0100, Igor Mammedov wrote:
On Mon, 04 Nov 2013 13:48:03 +0100
Gerd Hoffmann kra...@redhat.com wrote:
Hi,
So maybe design that with memory hotplug in mind? Such as adding a new
qemu-specific type QEMU_RAM_HOTPLUG? Which seabios could use to reserve
Hi,
Well, BIOS have to know where it could start 64-bit BARs mappings
and
telling it explicitly where, looks like a good way to do it.
As far as I can tell, BIOS can start any mappings anywhere it wants to
as long as they don't overlap anything else.
What is has to know is what
On Tue, 29 Oct 2013 20:52:42 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Oct 29, 2013 at 04:28:25PM +0100, Igor Mammedov wrote:
On Tue, 29 Oct 2013 17:10:47 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Oct 29, 2013 at 01:57:33PM +0100, Igor Mammedov wrote:
*
On Tue, 29 Oct 2013 20:52:42 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Oct 29, 2013 at 04:28:25PM +0100, Igor Mammedov wrote:
On Tue, 29 Oct 2013 17:10:47 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Oct 29, 2013 at 01:57:33PM +0100, Igor Mammedov wrote:
*
On Wed, Oct 30, 2013 at 02:24:54PM +0100, Igor Mammedov wrote:
On Tue, 29 Oct 2013 20:52:42 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Oct 29, 2013 at 04:28:25PM +0100, Igor Mammedov wrote:
On Tue, 29 Oct 2013 17:10:47 +0200
Michael S. Tsirkin m...@redhat.com wrote:
Hi,
I don't think we can predict the future.
It seems just as likely that BIOS will need to drive the
new hardware so it will not be enough to have start pci here.
In particular, non-contiguous hotpluggable memory does not seem all that
far-fetched, and we might want to put PCI devices in
On Wed, 30 Oct 2013 15:33:35 +0100
Gerd Hoffmann kra...@redhat.com wrote:
Hi,
I don't think we can predict the future.
It seems just as likely that BIOS will need to drive the
new hardware so it will not be enough to have start pci here.
In particular, non-contiguous hotpluggable
* simplify PCI address space mapping into system address space,
replacing code duplication in piix/q53 PCs with a helper function
* add fw_cfg 'etc/pcimem64-minimum-address' to allow QEMU reserve
additional address space before 64-bit PCI hole. Which will be
need for reserving memory
On Tue, Oct 29, 2013 at 01:57:33PM +0100, Igor Mammedov wrote:
* simplify PCI address space mapping into system address space,
replacing code duplication in piix/q53 PCs with a helper function
* add fw_cfg 'etc/pcimem64-minimum-address' to allow QEMU reserve
additional address space
On Tue, 29 Oct 2013 17:10:47 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Oct 29, 2013 at 01:57:33PM +0100, Igor Mammedov wrote:
* simplify PCI address space mapping into system address space,
replacing code duplication in piix/q53 PCs with a helper function
* add fw_cfg
On Tue, Oct 29, 2013 at 04:28:25PM +0100, Igor Mammedov wrote:
On Tue, 29 Oct 2013 17:10:47 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Oct 29, 2013 at 01:57:33PM +0100, Igor Mammedov wrote:
* simplify PCI address space mapping into system address space,
replacing code
13 matches
Mail list logo
