This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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

> 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