qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 for-2.9 0/3] q35: add negotiable broadcast SM


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH v3 for-2.9 0/3] q35: add negotiable broadcast SMI
Date: Fri, 25 Nov 2016 15:10:08 +0100

On Fri, 25 Nov 2016 03:55:29 -0500 (EST)
Paolo Bonzini <address@hidden> wrote:

> > > Parked CPUs are exactly how it works on real hardware (the arbitrator is
> > > the
> > > BMC, while we have QEMU in its place).  The problem is that, if you just
> > > place the hotplugged CPU in reset state, there is a race between the OSPM
> > > and the firmware.  The OSPM can place its own code at 0x30000 and send
> > > INIT/SIPI/SMI before the firmware gets round to doing it.  
> >
> > if 0x30000 were covered by SMRR range, then OSPM wouldn't able to
> > place its own code there and there wouldn't be any need in side interfaces
> > to put and get CPU in/from some undefined by spec state (parked).
> > 
> > But above would imply a large block allocated at 0x30000 to fit all
> > possible CPUs+1, not sure if it's doable (maybe edk2 wouldn't have
> > big issues with reserving large block in lowmem).  
> 
> If you mean that the default SMRR range would include 0x30000 for an 
> hotplugged
> CPU, that would work but it is a significant departure from real hardware.
> I'd rather avoid that.
But that's guest side only solution to guest problem, that won't require
any assistance from QEMU/KVM.
Baremetal would also benefit from it as it won't need to implement unpark
logic anymore. it should also work for existing HW that has unpark logic.

Do you have any pointers to how hardware does unparking now?

> > Suggestion to use CPU hotplug MMIO interface to unpark CPU also doesn't
> > seem to be secure as it's not protected from OSPM, hence OPSM could
> > unpark CPU and hijack SMBASE all the same.
> > It looks like we need only SMM accessible guest/host interface to make
> > CPU unparking secure or cover default SMBASE by SMRR.  
> 
> Yes, unparking would be accessible only from SMM if the unparking feature
> is negotiated.
I suppose we could check in MMIO handler that all CPUs are in SMM mode
before allowing unparking or ignore command if they are not.

For compat reasons unpark should be optin feature (i.e. firmware should
explicitly enable it to avoid breaking existing configurations (SeaBIOS))

> 
> Paolo
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]