[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable
From: |
Gerd Hoffmann |
Subject: |
Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable |
Date: |
Wed, 16 Feb 2022 09:19:17 +0100 |
On Tue, Feb 15, 2022 at 07:37:40PM +0000, Joao Martins wrote:
> On 2/15/22 09:53, Gerd Hoffmann wrote:
> > What is missing:
> >
> > * Some way for the firmware to get a phys-bits value it can actually
> > use. One possible way would be to have a paravirtual bit somewhere
> > telling whenever host-phys-bits is enabled or not.
> >
> If we are not talking about *very old* processors... isn't what already
> advertised in CPUID.80000008 EAX enough? That's the maxphysaddr width
> on x86, which on qemu we do set it with the phys-bits value;
Sigh. Nope. Did you read the complete reply?
Problem is this is not reliable. With host-phys-bits=off (default) qemu
allows to set phys-bits to whatever value you want, including values
larger than what the host actually supports. Which renders
CPUID.80000008.EAX unusable. To make things even worse: The default
value (phys-bits=40) is larger than what many intel boxes support.
host-phys-bits=on fixes that. It makes guest-phys-bits == host-phys-bits
by default, and also enforces guest-phys-bits <= host-phys-bits.
So with host-phys-bits=on the guest can actually use CPUID.80000008.EAX
to figure how big the guest physical address space is.
Problem is the guest doesn't know whenever host-phys-bits is enabled or
not ...
So the options to fix that are:
(1) Make the host-phys-bits option visible to the guest (as suggested
above), or
(2) Advertise a _reliable_ phys-bits value to the guest somehow.
take care,
Gerd
- [PATCH RFCv2 0/4] i386/pc: Fix creation of >= 1010G guests on AMD systems with IOMMU, Joao Martins, 2022/02/07
- [PATCH RFCv2 1/4] hw/i386: add 4g boundary start to X86MachineState, Joao Martins, 2022/02/07
- [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Joao Martins, 2022/02/07
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Igor Mammedov, 2022/02/14
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Joao Martins, 2022/02/14
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Igor Mammedov, 2022/02/14
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Gerd Hoffmann, 2022/02/15
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Joao Martins, 2022/02/15
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable,
Gerd Hoffmann <=
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Joao Martins, 2022/02/16
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Gerd Hoffmann, 2022/02/16
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Daniel P . Berrangé, 2022/02/16
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Dr. David Alan Gilbert, 2022/02/21
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Igor Mammedov, 2022/02/22
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Dr. David Alan Gilbert, 2022/02/22
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Gerd Hoffmann, 2022/02/22
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Igor Mammedov, 2022/02/23
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Dr. David Alan Gilbert, 2022/02/23
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Igor Mammedov, 2022/02/23