From: Igor Mammedov <imammedo@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"Jordan Justen (Intel address)" <jordan.l.justen@intel.com>,
qemu devel list <qemu-devel@nongnu.org>,
Kevin O'Connor <kevin@koconnor.net>,
Gerd Hoffmann <kraxel@redhat.com>,
Michael Kinney <michael.d.kinney@intel.com>,
Laszlo Ersek <lersek@redhat.com>
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 [thread overview]
Message-ID: <20161125151008.139e9f37@nial.brq.redhat.com> (raw)
In-Reply-To: <885040189.121652.1480064129384.JavaMail.zimbra@redhat.com>
On Fri, 25 Nov 2016 03:55:29 -0500 (EST)
Paolo Bonzini <pbonzini@redhat.com> 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
>
next prev parent reply other threads:[~2016-11-25 14:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-18 10:36 [Qemu-devel] [PATCH v3 for-2.9 0/3] q35: add negotiable broadcast SMI Laszlo Ersek
2016-11-18 10:36 ` [Qemu-devel] [PATCH v3 for-2.9 1/3] hw/isa/apm: introduce callback for APM_STS_IOPORT writes Laszlo Ersek
2016-11-18 10:36 ` [Qemu-devel] [PATCH v3 for-2.9 2/3] hw/isa/lpc_ich9: add SMI feature negotiation via APM_STS Laszlo Ersek
2016-11-18 10:36 ` [Qemu-devel] [PATCH v3 for-2.9 3/3] hw/isa/lpc_ich9: ICH9_APM_STS_F_BROADCAST_SMI: inject SMI on all VCPUs Laszlo Ersek
2016-11-18 14:10 ` [Qemu-devel] [PATCH v3 for-2.9 0/3] q35: add negotiable broadcast SMI Michael S. Tsirkin
2016-11-23 15:48 ` Laszlo Ersek
2016-11-23 22:35 ` Paolo Bonzini
2016-11-24 0:01 ` Laszlo Ersek
2016-11-24 0:31 ` Laszlo Ersek
2016-11-24 0:38 ` Kevin O'Connor
2016-11-24 4:29 ` Michael S. Tsirkin
2016-11-24 8:37 ` Laszlo Ersek
2016-11-25 4:00 ` Michael S. Tsirkin
2016-11-25 12:31 ` Laszlo Ersek
2016-11-25 12:40 ` Laszlo Ersek
2016-11-28 9:01 ` Gerd Hoffmann
2016-11-28 10:22 ` Laszlo Ersek
2016-11-28 11:53 ` Paolo Bonzini
2016-11-25 14:22 ` Igor Mammedov
2016-11-24 14:55 ` Igor Mammedov
2016-11-24 17:05 ` Paolo Bonzini
2016-11-24 18:02 ` Igor Mammedov
2016-11-25 8:55 ` Paolo Bonzini
2016-11-25 14:10 ` Igor Mammedov [this message]
2016-11-28 9:41 ` Paolo Bonzini
2016-11-28 11:24 ` Igor Mammedov
2016-11-28 11:51 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161125151008.139e9f37@nial.brq.redhat.com \
--to=imammedo@redhat.com \
--cc=jordan.l.justen@intel.com \
--cc=kevin@koconnor.net \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=michael.d.kinney@intel.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).