Hi,
> But why use 2G split instead of 3G? There's only very little MMIO and
> no PCI hole (including no huge MMCONFIG BAR) on microvm.
Yes, we can go for 3G, we are indeed not short on address space ;)
take care,
Gerd
Hi,
> > (1) we loose a bit of memory.
> it's probably not a big enough to care about, we do similar ovarlay
> mapping on pc/q35
> at the beginning of RAM
Yes, shouldn't be too much.
> > (2) we loose a gigabyte page.
> I'm not sure waht exactly we loose in thi
On 27/05/20 16:26, Igor Mammedov wrote:
> On Wed, 27 May 2020 15:06:28 +0200
> Paolo Bonzini wrote:
>
>> On 27/05/20 14:25, Igor Mammedov wrote:
(2) we loose a gigabyte page.
>>> I'm not sure waht exactly we loose in this case.
>>> Lets assume we allocating guest 5G o
On Wed, 27 May 2020 16:26:46 +0200
Igor Mammedov wrote:
> On Wed, 27 May 2020 15:06:28 +0200
> Paolo Bonzini wrote:
>
> > On 27/05/20 14:25, Igor Mammedov wrote:
> > >> (2) we loose a gigabyte page.
> > > I'm not sure waht exactly we loose in this case.
> > > Lets as
On Wed, 27 May 2020 15:06:28 +0200
Paolo Bonzini wrote:
> On 27/05/20 14:25, Igor Mammedov wrote:
> >> (2) we loose a gigabyte page.
> > I'm not sure waht exactly we loose in this case.
> > Lets assume we allocating guest 5G of continuous RAM using 1G
> > huge pages,
> >
On 27/05/20 14:25, Igor Mammedov wrote:
>> (2) we loose a gigabyte page.
> I'm not sure waht exactly we loose in this case.
> Lets assume we allocating guest 5G of continuous RAM using 1G huge
> pages,
> in this case I'd think that on host side MMIO overlay won't af
On Tue, 26 May 2020 06:48:39 +0200
Gerd Hoffmann wrote:
> > > Well, I think we can (should) drop max-ram-below-4g too. There is
> > > no reason to use that with microvm, other that shooting yourself into
> > > the foot (by making mmio overlap with ram).
> > >
> > > With that being gone too ther
> > Well, I think we can (should) drop max-ram-below-4g too. There is
> > no reason to use that with microvm, other that shooting yourself into
> > the foot (by making mmio overlap with ram).
> >
> > With that being gone too there isn't much logic left ...
>
> I wonder if we need 2G split for mi
On Mon, 25 May 2020 13:45:08 +0200
Gerd Hoffmann wrote:
> On Thu, May 21, 2020 at 11:29:21AM +0200, Igor Mammedov wrote:
> > On Wed, 20 May 2020 15:19:55 +0200
> > Gerd Hoffmann wrote:
> >
> > > Looks like the logiv was copied over from q35.
> > >
> > > q35 does this for backward compatibili
On Thu, May 21, 2020 at 11:29:21AM +0200, Igor Mammedov wrote:
> On Wed, 20 May 2020 15:19:55 +0200
> Gerd Hoffmann wrote:
>
> > Looks like the logiv was copied over from q35.
> >
> > q35 does this for backward compatibility, there is no reason to do this
> > on microvm though. So split @ 2G un
On Wed, 20 May 2020 15:19:55 +0200
Gerd Hoffmann wrote:
> Looks like the logiv was copied over from q35.
>
> q35 does this for backward compatibility, there is no reason to do this
> on microvm though. So split @ 2G unconditionally.
not related to your ACPI rework, but just an idea for future
On Wed, 20 May 2020 15:19:55 +0200
Gerd Hoffmann wrote:
> Looks like the logiv was copied over from q35.
>
> q35 does this for backward compatibility, there is no reason to do this
> on microvm though. So split @ 2G unconditionally.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Igor Mammedov
On 5/20/20 3:19 PM, Gerd Hoffmann wrote:
Looks like the logiv was copied over from q35.
Typo 'logiv' -> 'logic'.
q35 does this for backward compatibility, there is no reason to do this
on microvm though. So split @ 2G unconditionally.
Yes please!
Reviewed-by: Philippe Mathieu-Daudé
S
Looks like the logiv was copied over from q35.
q35 does this for backward compatibility, there is no reason to do this
on microvm though. So split @ 2G unconditionally.
Signed-off-by: Gerd Hoffmann
---
hw/i386/microvm.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
di
14 matches
Mail list logo
