On Tue, 8 Aug 2017 16:21:06 +1000
David Gibson <david@gibson.dropbear.id.au> 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.
> > >   
> 
> 
>