[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH] target/ppc: Only set PCR in kvm if actually in a
From: |
Greg Kurz |
Subject: |
Re: [Qemu-ppc] [PATCH] target/ppc: Only set PCR in kvm if actually in a compat mode |
Date: |
Tue, 8 Aug 2017 11:21:24 +0200 |
On Tue, 8 Aug 2017 16:21:06 +1000
David Gibson <address@hidden> wrote:
[...]
> > > >
> > > > Does it make sense at all to use compat mode with KVM_PR since it
> > > > requires hypervisor privilege, that we're supposed not to have ?
> > >
> > > Uh.. what? Availability of the PCR is a question of the guest
> > > environment, and PR (at least potentially) supports various different
> > > guest environments, both with and without (apparent) hypervisor
> > > capability.
> > >
> >
> > I mean mtpcr/mfpcr only work when the CPU is in hypervisor state, and PR
> > is supposed to be *mostly* used nested, ie, without hypervisor
> > privilege.
>
> It tends to be used that way, but it doesn't have to be.
>
> > Thus, I don't see the point in implementing PPC_ARCH_COMPAT in PR... but
> > I'm probably missing something :)
>
> Well, qemu expects to be able to set ARCH_COMPAT for a pseries guest,
> if that guest is going into a compatibility mode (which it usually
> does these days). We don't want userspace to have to be constantly
> checking which KVM implementation its working against, so it makes
> sense for PR to implement the call, even if it's a no-op because it
> can't really implement the PCR fully.
>
Thanks for the explanation!
> >
> > > > Shouldn't we check for kvm_get_one_reg(KVM_REG_PPC_ARCH_COMPAT) and
> > > > don't try to do any compat stuff if it isn't supported ? This would
> > > > include exiting QEMU if max-cpu-compat was passed on the cmdline.
> > >
> > > Oh.. right.. that's actually what I meant by setting the PCR. PCR
> > > setting from the userspace side via PPC_ARCH_COMPAT, rather than PCR
> > > setting from the guest side.
> > >
>
>
>
pgpApxJX3X2vj.pgp
Description: OpenPGP digital signature