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][QEMU] Fix ACPI COM port detection

To: Gary Grebus <ggrebus@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][QEMU] Fix ACPI COM port detection
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Tue, 28 Aug 2007 14:56:02 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ben Guthro <bguthro@xxxxxxxxxxxxxxx>
Delivery-date: Tue, 28 Aug 2007 06:56:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1188308777.2737.331.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfpeytMaeu73VVuEdyEfAAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH][QEMU] Fix ACPI COM port detection
User-agent: Microsoft-Entourage/
On 28/8/07 14:46, "Gary Grebus" <ggrebus@xxxxxxxxxxxxxxx> wrote:

> On Tue, 2007-08-28 at 12:57 +0100, Keir Fraser wrote:
>> A bit of fiddling seems to indicate that dynamically presenting the UAR
>> devices does actually make sense. Windows doesn't complain about all COM
>> ports going missing in the same way that it does about all LPT ports going
>> missing. And it does complain (albeit hidden in device manager and event
>> viewer) if it sees a ACPI UAR device that it can't physically probe.
> Those two complaints were what the patch was intended to address.

It would save me time if that was explained in the patch comment. Working
out the motivating reason for a patch is one of the more tedious parts of

>>> Also, PIIX4 is not hardcoded to 00:01.2, and if it moves then we have set
>>> ourselves up here for a subtle bug.
> True, but I don't know of any way around having the DSDT know at least a
> little about the device model.

Hvmloader already probes the PCI space. I think we should have a small
in-memory info structure immediately preceding the loaded ACPI tables, in a
format agreed between hvmloader and the DSDT. Hvmloader can populate it and
DSDT can maintain it. Since the ACPI tables are part of hvmloader, in source
and in binary, this dependency is quite acceptable.

 -- Keir

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>