On Tue, 15 Oct 2013 11:24:19 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > > What is the state of the qemu side patches btw?
> > > I've them ready but they conflict with you 1Tb in e820 RFC,
> > > I can post relevant patches as soon as we agree on this topic.
> > > May I pick up your patch and post
On Tue, 15 Oct 2013 12:16:43 +0300
"Michael S. Tsirkin" wrote:
> On Tue, Oct 15, 2013 at 11:05:48AM +0200, Igor Mammedov wrote:
> > On Tue, 15 Oct 2013 10:01:01 +0200
> > Gerd Hoffmann wrote:
> >
> > > Hi,
> > >
> > > > Yes but at the cost of overspecifying it.
> > > > I think it's down to t
Hi,
> > > What is the state of the qemu side patches btw?
> > I've them ready but they conflict with you 1Tb in e820 RFC,
> > I can post relevant patches as soon as we agree on this topic.
> > May I pick up your patch and post it along with pcimem64-start patches?
>
> So for qemu we really need
On Tue, Oct 15, 2013 at 11:05:48AM +0200, Igor Mammedov wrote:
> On Tue, 15 Oct 2013 10:01:01 +0200
> Gerd Hoffmann wrote:
>
> > Hi,
> >
> > > Yes but at the cost of overspecifying it.
> > > I think it's down to the name: it's called pcimem64-start
> > > but it can actually be less than 4G and
On Tue, 15 Oct 2013 10:01:01 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > Yes but at the cost of overspecifying it.
> > I think it's down to the name: it's called pcimem64-start
> > but it can actually be less than 4G and we need to worry what to
> > do then. Also, 64 doesn't really mean >4G.
> >
>
On Tue, Oct 15, 2013 at 10:01:01AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > Yes but at the cost of overspecifying it.
> > I think it's down to the name: it's called pcimem64-start
> > but it can actually be less than 4G and we need to worry what to
> > do then. Also, 64 doesn't really mean >4G.
>
Hi,
> Yes but at the cost of overspecifying it.
> I think it's down to the name: it's called pcimem64-start
> but it can actually be less than 4G and we need to worry what to
> do then. Also, 64 doesn't really mean >4G.
>
> So how about "reserve-memory-over-4g"?
> bios then does 1ull << 32 + re
On Mon, Oct 14, 2013 at 06:15:25PM +0200, Igor Mammedov wrote:
> On Mon, 14 Oct 2013 17:00:47 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Mon, Oct 14, 2013 at 03:04:45PM +0200, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > >
> > > > > To me it makes more sense to just go the direct route and
On Mon, 14 Oct 2013 17:00:47 +0300
"Michael S. Tsirkin" wrote:
> On Mon, Oct 14, 2013 at 03:04:45PM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > >
> > > > To me it makes more sense to just go the direct route and say "please
> > > > put the 64bit bars at this location" rather than indirect "
On Mon, Oct 14, 2013 at 03:04:45PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > >
> > > To me it makes more sense to just go the direct route and say "please
> > > put the 64bit bars at this location" rather than indirect "we might want
> > > hotplug $thatmuch memory" and then expect the bios to lea
Hi,
> >
> > To me it makes more sense to just go the direct route and say "please
> > put the 64bit bars at this location" rather than indirect "we might want
> > hotplug $thatmuch memory" and then expect the bios to leave that much
> > room.
>
> Only if the newfeature address is not under bio
On Mon, Oct 14, 2013 at 02:16:23PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > And there is slight difference between PCI holes and PCI address space
> > > mappings
> > > represented by MemoryRegion-s in QEMU.
> > >
> > > Basically we only need to inform BIOS where to PCI address spaces start
>
On Mon, 14 Oct 2013 14:00:12 +0300
"Michael S. Tsirkin" wrote:
> On Mon, Oct 14, 2013 at 12:27:26PM +0200, Igor Mammedov wrote:
> > On Sun, 13 Oct 2013 23:28:47 +0300
> > "Michael S. Tsirkin" wrote:
> >
> > > On Sun, Oct 13, 2013 at 07:33:19PM +0200, Igor Mammedov wrote:
> > > > On Sun, 13 Oct
Hi,
> > And there is slight difference between PCI holes and PCI address space
> > mappings
> > represented by MemoryRegion-s in QEMU.
> >
> > Basically we only need to inform BIOS where to PCI address spaces start and
> > simple "etc/pcimem64-start" + "etc/pcimem32-start" are just fine for th
On Mon, Oct 14, 2013 at 12:27:26PM +0200, Igor Mammedov wrote:
> On Sun, 13 Oct 2013 23:28:47 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Sun, Oct 13, 2013 at 07:33:19PM +0200, Igor Mammedov wrote:
> > > On Sun, 13 Oct 2013 19:46:09 +0300
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > On Sun,
On Sun, 13 Oct 2013 23:28:47 +0300
"Michael S. Tsirkin" wrote:
> On Sun, Oct 13, 2013 at 07:33:19PM +0200, Igor Mammedov wrote:
> > On Sun, 13 Oct 2013 19:46:09 +0300
> > "Michael S. Tsirkin" wrote:
> >
> > > On Sun, Oct 13, 2013 at 06:23:28PM +0200, Igor Mammedov wrote:
> > > > On Sun, 13 Oct
On Sun, Oct 13, 2013 at 07:33:19PM +0200, Igor Mammedov wrote:
> On Sun, 13 Oct 2013 19:46:09 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Sun, Oct 13, 2013 at 06:23:28PM +0200, Igor Mammedov wrote:
> > > On Sun, 13 Oct 2013 18:59:20 +0300
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > On Sun,
On Sun, 13 Oct 2013 19:46:09 +0300
"Michael S. Tsirkin" wrote:
> On Sun, Oct 13, 2013 at 06:23:28PM +0200, Igor Mammedov wrote:
> > On Sun, 13 Oct 2013 18:59:20 +0300
> > "Michael S. Tsirkin" wrote:
> >
> > > On Sun, Oct 13, 2013 at 05:11:54PM +0200, Igor Mammedov wrote:
> > > > On Sun, 13 Oct
On Sun, Oct 13, 2013 at 06:23:28PM +0200, Igor Mammedov wrote:
> On Sun, 13 Oct 2013 18:59:20 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Sun, Oct 13, 2013 at 05:11:54PM +0200, Igor Mammedov wrote:
> > > On Sun, 13 Oct 2013 15:31:23 +0300
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > On Sun,
On Sun, 13 Oct 2013 18:59:20 +0300
"Michael S. Tsirkin" wrote:
> On Sun, Oct 13, 2013 at 05:11:54PM +0200, Igor Mammedov wrote:
> > On Sun, 13 Oct 2013 15:31:23 +0300
> > "Michael S. Tsirkin" wrote:
> >
> > > On Sun, Oct 13, 2013 at 02:13:44PM +0200, Igor Mammedov wrote:
> > > > Currently 64-bi
On Sun, Oct 13, 2013 at 05:11:54PM +0200, Igor Mammedov wrote:
> On Sun, 13 Oct 2013 15:31:23 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Sun, Oct 13, 2013 at 02:13:44PM +0200, Igor Mammedov wrote:
> > > Currently 64-bit PCI BARs are unconditionally mapped by BIOS right
> > > over 4G + RamSizeOv
On Sun, Oct 13, 2013 at 03:31:23PM +0300, Michael S. Tsirkin wrote:
> On Sun, Oct 13, 2013 at 02:13:44PM +0200, Igor Mammedov wrote:
> > Currently 64-bit PCI BARs are unconditionally mapped by BIOS right
> > over 4G + RamSizeOver4G location, which doesn't allow to reserve
> > extra space before 64-
On Sun, 13 Oct 2013 15:31:23 +0300
"Michael S. Tsirkin" wrote:
> On Sun, Oct 13, 2013 at 02:13:44PM +0200, Igor Mammedov wrote:
> > Currently 64-bit PCI BARs are unconditionally mapped by BIOS right
> > over 4G + RamSizeOver4G location, which doesn't allow to reserve
> > extra space before 64-bit
On Sun, Oct 13, 2013 at 02:13:44PM +0200, Igor Mammedov wrote:
> Currently 64-bit PCI BARs are unconditionally mapped by BIOS right
> over 4G + RamSizeOver4G location, which doesn't allow to reserve
> extra space before 64-bit PCI window. For memory hotplug an extra
> RAM space might be reserved af
Currently 64-bit PCI BARs are unconditionally mapped by BIOS right
over 4G + RamSizeOver4G location, which doesn't allow to reserve
extra space before 64-bit PCI window. For memory hotplug an extra
RAM space might be reserved after present 64-bit RAM end and BIOS
should map 64-bit PCI BARs after it
25 matches
Mail list logo
