Hi,
> Ok, then would "etc/pcimem64-start" be suitable or maybe you have a
> suggestion?
Looks good to me.
cheers,
Gerd
On Thu, 10 Oct 2013 15:21:55 +0200
Gerd Hoffmann 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 do
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 "
On Thu, 10 Oct 2013 15:21:32 +0300
"Michael S. Tsirkin" 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
On Thu, 10 Oct 2013 14:42:07 +0200
Gerd Hoffmann 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
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 sur
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 fo
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 seab
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
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
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 loca
On Wed, 09 Oct 2013 15:12:08 +0200
Gerd Hoffmann 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 located right
>
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
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
64
14 matches
Mail list logo
