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-devel

RE: [Xen-devel] [PATCH][RFC] Support more Capability StructuresandDevice

To: "Yuji Shimada" <shimada-yxb@xxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH][RFC] Support more Capability StructuresandDevice Specific
From: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Date: Mon, 30 Jun 2008 17:02:20 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 30 Jun 2008 02:02:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080630161349.F321.SHIMADA-YXB@xxxxxxxxxxxxxxx>
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: <C48A7D55.232F0%keir.fraser@xxxxxxxxxxxxx><10EA09EFD8728347A513008B6B0DA77A035B4F6F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080630161349.F321.SHIMADA-YXB@xxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjagRm1roxLUvZYQ02KSpYoo3QgkQAB293Q
Thread-topic: [Xen-devel] [PATCH][RFC] Support more Capability StructuresandDevice Specific
I didn't work on the memory mapped access machinism.
I'm not sure whether adding that support is OK since now Qemu emulates an old 
chipset which is actually PCIe-unaware.

Thanks,
-- Dexuan


-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Yuji Shimada
Sent: 2008年6月30日 15:15
To: Dong, Eddie
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Ian Jackson; Keir Fraser
Subject: Re: [Xen-devel] [PATCH][RFC] Support more Capability 
StructuresandDevice Specific

I think it is better to emulate registers related to error reporting
at least.

We can consider two patterns of error handling as following.

PATTERN-1: AER is enabled on host but will not be notified to guest domain.

Actual AER is enable, but guest software is not allowed to enable AER
by _OSC in guest firmware. When error occurs, dom0 will kill guest
domain and reset the device or bus. Registers related to error
reporting should be emulated to prevent guest software turning off
actual error reporting.

PATTERN-2: AER is enabled on host and will also be notified to guest domain.

Actual AER is always enable, but guest can enable/disable its virtual
AER. When error occurs, dom0 check guest emulated AER is enabled or not.
If guest emulated AER is enabled, dom0 will notify error to guest
software. Then guest software will reset I/O device or bus.
If guest emulated AER is disabled, dom0 will not notify error to
guest software. Dom0 will kill guest domain, and reset I/O device or
bus. To do this, registers related to error reporting should be
emulated. And Root Port emulation is also required.


I've taken a look at "Xen - VT-D Enhance.pdf".

Is Dexuan implementing Memory Mapped Configuration Access Mechanism to
support offset 256-4095? Are following interfaces not changed ?

    pci_dev->config_read
    pci_dev->config_write

If they are not changed, I think Dexuan's Memory Mapped Configuration
Access Mechanism and my code can be merged easily.

Thanks a lot.

--
Yuji Shimada

> Keir Fraser wrote:
> > What do you think of Yuji's patch? One thing to consider
> > is that perhaps the patch should be against the upstream
> > qemu merge now. But I'm not sure that PCI passthrough is
> > even supported yet in that tree (Ian?). 
> > 
> 
> If we agree the basic policy is pass through except the ones with known
> behavior, I think we don't need that many case to case handle. Dexuan is
> working on the implementation base on the summit talk and close to end,
> maybe Yuji and Dexuan can coordinate first to see if the proposed policy
> can server yuji's purpose.
> 
> Thx, eddie
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


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

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

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