 Home |
Products |
Support |
Community |
News |
xen-devel
Re: [Xen-devel] [PATCH V2] hvmloader: Fix FADT table for QEMU Upstream.
| To: | Keir Fraser <keir@xxxxxxx> |
|---|---|
| Subject: | Re: [Xen-devel] [PATCH V2] hvmloader: Fix FADT table for QEMU Upstream. |
| From: | Anthony PERARD <anthony.perard@xxxxxxxxxx> |
| Date: | Wed, 27 Jul 2011 17:00:09 +0100 |
| Cc: | Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Tobias Geiger <tobias.geiger@xxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx> |
| Delivery-date: | Wed, 27 Jul 2011 09:04:34 -0700 |
| Dkim-signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=1nkAzyePhYv0LSFeok2hmAKIOJB/viWR2iZXOUaKW2w=; b=wbR2wmZmlfw7YMcjjl21/nv0gggk59rtze1dNMCN82Hpg6172hgbtNJ/xKVPcd7Z2H 0AltfFwfigsVgrkVCtRqwkxVQVpnkcu48TxnV0b4VbEW8cR8US0rjqq9IJSK8Hpx20oV Em/hqXx9okkApvqYiLfszXg6tPw/NAqMFQbPg= |
| Envelope-to: | www-data@xxxxxxxxxxxxxxxxxxx |
| In-reply-to: | <CA54BC8E.2FB73%keir@xxxxxxx> |
| List-help: | <mailto:xen-devel-request@lists.xensource.com?subject=help> |
| List-id: | Xen developer discussion <xen-devel.lists.xensource.com> |
| List-post: | <mailto:xen-devel@lists.xensource.com> |
| List-subscribe: | <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
| List-unsubscribe: | <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
| References: | <1311690181-32378-1-git-send-email-anthony.perard@xxxxxxxxxx> <CA54BC8E.2FB73%keir@xxxxxxx> |
| Sender: | xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
On Tue, Jul 26, 2011 at 18:48, Keir Fraser <keir@xxxxxxx> wrote: > Thinking about this some more I wonder whether this will be correct for old > Qemu. Furthermore, we don't actually have a legacy/SMM component in our > virtual firmware, so advertising the enable/disable mechanism via > SMI_CMD_IOPORT is a bit pointless. > > Could we instead dynamically handle this in in hvmloader's acpi-handling > code something like: > if ( !SCI_EN ) // must be new qemu if so > outb(SMI_CMD_IOPORT, PIIX4_ACPI_ENABLE) > BUG_ON(!SCI_EN) I just try that, and that works fine. So it's fine to me to do that instead of providing an IOPort that is not handle by the qemu-xen-legacy. > Or alternatively, we should at least gate the setting of those FADT fields > on such a check, it seems to me. -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [Xen-devel] Re: [PATCH 0/5] Collected vdso/vsyscall fixes for 3.1, Konrad Rzeszutek Wilk |
|---|---|
| Next by Date: | Re: [Xen-devel] [semi-urgent Xen CS question] Re: git commit 9fd67b4ed0714ab718f1f9bd14c344af336a6df7 (x86-64: Give vvars their own page) breaks Xen PV guests (64-bit)., Andrew Lutomirski |
| Previous by Thread: | Re: [Xen-devel] [PATCH V2] hvmloader: Fix FADT table for QEMU Upstream., Keir Fraser |
| Next by Thread: | Re: [Xen-devel] [PATCH V2] hvmloader: Fix FADT table for QEMU Upstream., Keir Fraser |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
