All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Jordan Justen <jordan.l.justen@intel.com>,
	Laszlo Ersek <lersek@redhat.com>,
	Kevin O'Connor <kevin@koconnor.net>
Cc: Michael Kinney <michael.d.kinney@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] hw/isa/lpc_ich9: inject the SMI on the VCPU that is writing to APM_CNT
Date: Fri, 23 Oct 2015 20:24:51 +0200	[thread overview]
Message-ID: <562A7B73.7080604@redhat.com> (raw)
In-Reply-To: <20151023182032.29864.87635@jljusten-ivb>



On 23/10/2015 20:20, Jordan Justen wrote:
>>>> It's not worth the hassle to relocate the SMBASE of the APs?
>>>> So, basically, write to 0x30000-0x38000, then send an SMI IPI to the
>>>> AP and now you have the AP running in SMI and it has extra privileges?
>>>
>>> Extra privileges compared to what?  Legacy BIOS does not really put
>>> anything privileged in SMRAM,
> 
> Why does seabios even bother relocating the BSP's SMBASE if it doesn't
> relocate the SMBASE for the APs?

It uses SMM to run INT 13h in 32-bit real mode, basically.  It's for
MS-DOS usage only, so the APs don't matter.

>> So what are we thinking about a magic APM_STS value to trigger an SMI
>> for all VCPUs? 0x51 ('Q') would be cool. :)
> 
> This seems like a further deviation from the actual hardware. I
> understand that QEMU draws a line about strict hardware emulation, but
> I just wanted to point out the discrepancy.

Yeah, I am also a bit doubtful about that.

> So, the trouble with changing QEMU to better emulate the hardware is
> that seabios can't handle multiple processors entering SMM?

Yes.

Paolo

  reply	other threads:[~2015-10-23 18:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-20 18:14 [Qemu-devel] [PATCH] hw/isa/lpc_ich9: inject the SMI on the VCPU that is writing to APM_CNT Laszlo Ersek
2015-10-21  9:49 ` Paolo Bonzini
2015-10-21 10:29   ` Michael S. Tsirkin
2015-10-21 18:36 ` Jordan Justen
2015-10-22  8:40   ` Paolo Bonzini
2015-10-22  9:50     ` Laszlo Ersek
2015-10-22  9:54       ` Paolo Bonzini
2015-10-22 18:04     ` Kevin O'Connor
2015-10-22 19:46       ` Paolo Bonzini
2015-10-23  4:41         ` Jordan Justen
2015-10-23  7:26           ` Paolo Bonzini
2015-10-23 12:53             ` Laszlo Ersek
2015-10-23 18:20               ` Jordan Justen
2015-10-23 18:24                 ` Paolo Bonzini [this message]
2015-10-23 21:25                 ` Laszlo Ersek
2015-10-23 16:54             ` Kevin O'Connor
2015-10-23 17:00               ` 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=562A7B73.7080604@redhat.com \
    --to=pbonzini@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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.