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: "Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel]Question about qemu interrupt deliver.
From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Date: Thu, 30 Nov 2006 10:52:43 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 29 Nov 2006 18:53:43 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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+AACFyCIA=
Thread-topic: [Xen-devel]Question about qemu interrupt deliver.
Keir Fraser write on 2006年11月29日 18:28:
> On 29/11/06 10:20, "Keir Fraser" <keir@xxxxxxxxxxxxx> wrote:
> 
>> There is always
>> the option of allowing the mapping to be dynamically specified to
>> Xen in future (e.g., hvmloader could make a choice, install the
>> appropriate ACPI DSDT and use a new hypercall to dynamically modify
>> PCI->link and PCI->GSI information). It's not clear that level of
>> flexibility will be warranted though -- 32 non-legacy GSIs should be
>> plenty to avoid sharing even with a static barber-pole INTx->GSI
>> mapping. 
> 
> Actually I can be more precise than this. I *would* have allowed
> dynamic INTx->GSI mapping if it were easy to generate the _PRT in the
> ACPI DSDT. Then hvmloader could walk the PCI bus, find all INTx
> lines, and map them all to unique GSIs. That would be very nice.
> *But* the _PRT is embedded in the DSDT and so generating it during
> boot is (as far as I am aware) basically impossible. So since the
> _PRT is static, the mapping in Xen may as well be static too.
> 
> I'd be very interested in knowing if there are any tricks to inject
> dynamic info into the DSDT (e.g., could the _PRT be dynamically
> generated in AML based on memory values poked by hvmloader?).
> 

Hi Keir,

Thanks for your detailed description

But I have below concerns.

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.



Anthony

>  -- Keir

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