Hi,
Ok, then would etc/pcimem64-start be suitable or maybe you have a
suggestion?
Looks good to me.
cheers,
Gerd
Hi,
So far from QEMU side it's partially (only memory region mapping and not ACPI
window) configurable via {i440FX-pcihost|q35-pcihost}.pci-hole64-size property
/me looks.
Hmm, so the pci-hole64 memory region basically covers all non-memory
area, leaving no free space.
The window
On Thu, Oct 10, 2013 at 12:56:23PM +0200, Gerd Hoffmann wrote:
Hi,
So far from QEMU side it's partially (only memory region mapping and not
ACPI
window) configurable via {i440FX-pcihost|q35-pcihost}.pci-hole64-size
property
/me looks.
Hmm, so the pci-hole64 memory region
On Wed, Oct 09, 2013 at 02:23:04PM +0200, Igor Mammedov wrote:
I'm posting it to get an oppinion on one of possible approaches
on where to map a hotplug memory.
This patch assumes that a space for hotplug memory is located right
after RamSizeOver4G region and QEMU will provide romfile to
Hi,
I think the simplest way to do all this is simply to tell seabios
that we have more memory. seabios already programs 64 bit BARs
higher than memory.
Hmm? As I understand Igor just wants some address space for memory
hotplug. So there wouldn't be memory there (yet). And telling
On Thu, Oct 10, 2013 at 02:14:16PM +0200, Gerd Hoffmann wrote:
Hi,
I think the simplest way to do all this is simply to tell seabios
that we have more memory. seabios already programs 64 bit BARs
higher than memory.
Hmm? As I understand Igor just wants some address space for memory
Hi,
I think the issue is with legacy guests.
E.g. if VCPU claims to support 50 bit of memory
do we put high PCI memory at 1 50?
If yes old guests which expect at most 40 bit
will not be able to use it.
Hmm. Sure such guests exist?
I wouldn't be surprised. At least some
On Thu, 10 Oct 2013 14:42:07 +0200
Gerd Hoffmann kra...@redhat.com wrote:
Hi,
I think the issue is with legacy guests.
E.g. if VCPU claims to support 50 bit of memory
do we put high PCI memory at 1 50?
If yes old guests which expect at most 40 bit
will not be able to use
On Thu, 10 Oct 2013 15:21:32 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Oct 10, 2013 at 02:14:16PM +0200, Gerd Hoffmann wrote:
Hi,
I think the simplest way to do all this is simply to tell seabios
that we have more memory. seabios already programs 64 bit BARs
higher
Hi,
Guess we can just go with Igor's approach then. etc/mem64-end is a
pretty bad name to say please map 64bit pci bars here though.
reasoning bind was to tell BIOS where RAM ends and let it decide what
to do with this information.
But we could do other way around and use etc/pci-info
On Thu, 10 Oct 2013 15:21:55 +0200
Gerd Hoffmann kra...@redhat.com wrote:
Hi,
Guess we can just go with Igor's approach then. etc/mem64-end is a
pretty bad name to say please map 64bit pci bars here though.
reasoning bind was to tell BIOS where RAM ends and let it decide what
to
I'm posting it to get an oppinion on one of possible approaches
on where to map a hotplug memory.
This patch assumes that a space for hotplug memory is located right
after RamSizeOver4G region and QEMU will provide romfile to specify
where it ends so that BIOS could know from what base to start
On Mi, 2013-10-09 at 14:23 +0200, Igor Mammedov wrote:
I'm posting it to get an oppinion on one of possible approaches
on where to map a hotplug memory.
This patch assumes that a space for hotplug memory is located right
after RamSizeOver4G region and QEMU will provide romfile to specify
On Wed, 09 Oct 2013 15:12:08 +0200
Gerd Hoffmann kra...@redhat.com wrote:
On Mi, 2013-10-09 at 14:23 +0200, Igor Mammedov wrote:
I'm posting it to get an oppinion on one of possible approaches
on where to map a hotplug memory.
This patch assumes that a space for hotplug memory is
14 matches
Mail list logo
