[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: |
Igor Mammedov |
Subject: |
Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable |
Date: |
Wed, 23 Feb 2022 10:31:51 +0100 |
On Wed, 23 Feb 2022 09:16:51 +0000
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * Igor Mammedov (imammedo@redhat.com) wrote:
> > On Tue, 22 Feb 2022 10:42:55 +0100
> > Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > > Hi,
> > >
> > > > > And the upstream code is now pretty much identical except for the
> > > > > default; note that for TCG you do need to keep to 40 I think.
> > > >
> > > > will TCG work with 40bits on host that supports less than that?
> > >
> > > When I understand things correctly the problem is that the phys-bits
> > > limit applies to the npt/ept tables too, effectively restricting guest
> > > physical address space to host physical address space.
> > >
> > > TCG is not affected by that and should work just fine.
> > >
> > > Not sure what happens if you turn off npt/ept and run on softmmu.
> > > Possibly that works fine too.
> > >
> > > > Also quick look at host-phys-bits shows that it affects only 'host'
> > > > cpu model and is NOP for all other models.
> > >
> > > I don't think so. microvm forces host-phys-bits=on and that works with
> > > all cpu models.
> >
> > I just don't see how host-phys-bits can work for other than 'host' cpu
> > model.
> > It's true that property is available for all cpu models, but the field it
> > sets
> > is only used in target/i386/host-cpu.c, the same applies to
> > host-phys-bits-limit.
> > Am I missing something?
>
> The hook in kvm/kvm-cpu.c kvm_cpu_realizefn:
>
> /*
> * The realize order is important, since x86_cpu_realize() checks if
> * nothing else has been set by the user (or by accelerators) in
> * cpu->ucode_rev and cpu->phys_bits, and updates the CPUID results in
> * mwait.ecx.
> * This accel realization code also assumes cpu features are already
> expanded.
> *
> * realize order:
> *
> * x86_cpu_realize():
> * -> x86_cpu_expand_features()
> * -> cpu_exec_realizefn():
> * -> accel_cpu_realizefn()
> * kvm_cpu_realizefn() -> host_cpu_realizefn()
> * -> check/update ucode_rev, phys_bits, mwait
> */
Thanks,
I didn't expect host_cpu_realizefn being called from elsewhere
beside of cpu model it belongs to or models inherited from it.
>
> Dave
>
> > >
> > > take care,
> > > Gerd
> > >
> >
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, (continued)
- 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 <=
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Joao Martins, 2022/02/18
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Igor Mammedov, 2022/02/21
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Joao Martins, 2022/02/21
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Joao Martins, 2022/02/22
- Re: [PATCH RFCv2 2/4] i386/pc: relocate 4g start to 1T where applicable, Igor Mammedov, 2022/02/23
[PATCH RFCv2 4/4] i386/pc: Restrict AMD-only enforcing of valid IOVAs to new machine type, Joao Martins, 2022/02/07
[PATCH RFCv2 3/4] i386/pc: warn if phys-bits is too low, Joao Martins, 2022/02/07