On Mo, 2013-11-04 at 15:35 +0100, Igor Mammedov wrote:
> On Mon, 04 Nov 2013 13:48:03 +0100
> Gerd Hoffmann 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
> >
On Mon, 04 Nov 2013 13:48:03 +0100
Gerd Hoffmann 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)?
> > It
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 Wed, 30 Oct 2013 15:33:35 +0100
Gerd Hoffmann 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 do
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 devic
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" 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" wrote:
> > >
> > > > On Tue,
On Tue, 29 Oct 2013 20:52:42 +0200
"Michael S. Tsirkin" 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" wrote:
> >
> > > On Tue, Oct 29, 2013 at 01:57:33PM +0100, Igor Mammedov wrote:
> > > > * simplify PCI
On Tue, 29 Oct 2013 20:52:42 +0200
"Michael S. Tsirkin" 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" wrote:
> >
> > > On Tue, Oct 29, 2013 at 01:57:33PM +0100, Igor Mammedov wrote:
> > > > * simplify PCI
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 w
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" 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 dupli
On Tue, 29 Oct 2013 17:10:47 +0200
"Michael S. Tsirkin" 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 'etc/pc
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
* 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 hotplug
13 matches
Mail list logo
