WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-devel]Question about qemu interrupt deliver.

To: "Xu, Anthony" <anthony.xu@xxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel]Question about qemu interrupt deliver.
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Thu, 30 Nov 2006 09:15:09 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 30 Nov 2006 01:15:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <51CFAB8CB6883745AE7B93B3E084EBE207DD78@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: AccTi/UCWhQFxKqBSYWUgXBidhb4LgAAe01hAAAWaeAABHI+WgAAQk+AACFyCIAADkyACw==
Thread-topic: [Xen-devel]Question about qemu interrupt deliver.
User-agent: Microsoft-Entourage/11.2.5.060620
1a. If there is opportunity for code reuse we should aim for it. I'd be
happy to see a root hvm/ directory. Clearly the IOAPIC code is already
shared and that could be made more explicit by moving the source file.

1b. I don't care about the hypervisor getting bigger if the alternative is
simply pushing code into other critical components. If the device models are
buggy then HVM domains do not work -- it doesn't matter whether the code is
in Xen or in qemu-dm. In some respects I prefer the former as I will tend to
audit Xen code more aggressively. There is a downside that the effects of
bad code may not be limited to a single guest but we should be aiming for
high-quality code regardless of the context in which it executes.

2. I browsed a few drivers and concluded that most have correct INTx
assertion behaviour. Any that don't should be fixed. Hacks like the 0-1
pulse done for periodic timers need addressing in a future patch, for
example.

 -- Keir

On 30/11/06 02:52, "Xu, Anthony" <anthony.xu@xxxxxxxxx> wrote:

> 1.  PCI->link and PCI->GSI are put into hypervisor. But it is under x86
> directory,
>      it's not convenient for other architecture to share these information.
> 
>      Seems there is a trend, we move code from other component into
> hypersivor,
>      is there any criteria whether we should move code into hypersivor?
> Otherwise 
>     hypersivor  will become bigger and bigger quickly, that's not definitely
> what we want.
> 
> 2.  hypervisor uses hvm_irq->gsi_assert_count[gsi] to emulate level triggered
> interrupt.
>     The code itself is correct, but it sets a high stardant for PCI device
> emulator, it PCI device
>      emulator set irq_line low/hight twice continuously, that will lead to
> interrupt lost or spurios
>      interrupt.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel