Xen devel - Apr 2008 - [PATCH][RFC]Move PCI Configuration Spaces from Dom0 to Xen

Hi, Keir,

This patch will move reading and writing of PCI configuration spaces
from dom0 to Xen. It also changes VTD code, so that they can touch the
PCI configuration spaces with proper lock.
This will also benefit MSI support in Xen.
Can you give some comments? Thanks!
 <<pci_conf_xen.patch>> 

Best Regards
Haitao Shan




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

On 10/4/08 10:45, "Shan, Haitao" <haitao.shan@intel.com> wrote:
> This patch will move reading and writing of PCI configuration spaces from
dom0
> to Xen. It also changes VTD code, so that they can touch the PCI
configuration
> spaces with proper lock.
> 
> This will also benefit MSI support in Xen.
> Can you give some comments? Thanks!
The approach is fine. I will read it more thoroughly, clean it up a bit if
necessary, and certainly check it in.

 -- Keir



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

Thanks, Keir!

2008/4/10, Keir Fraser
<keir.fraser@eu.citrix.com>:
>
>  On 10/4/08 10:45, "Shan, Haitao" <haitao.shan@intel.com>
wrote:
>
> This patch will move reading and writing of PCI configuration spaces from
> dom0 to Xen. It also changes VTD code, so that they can touch the PCI
> configuration spaces with proper lock.
>
> This will also benefit MSI support in Xen.
> Can you give some comments? Thanks!
>
>
> The approach is fine. I will read it more thoroughly, clean it up a bit if
> necessary, and certainly check it in.
>
>  -- Keir
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

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

I believe dword writes to 0xCF8 should always be latched into the
internal shadow register, irrespective of whether the enable bit (bit
31) is set.  Accesseses to 0xCFC can then safely be skipped if enable
bit in latch register is not set.

	eSk



[Haitao Shan]
> Thanks, Keir!
> 2008/4/10, Keir Fraser <keir.fraser@eu.citrix.com>:
>> 
>> On 10/4/08 10:45, "Shan, Haitao"
<haitao.shan@intel.com> wrote:
>> 
>> This patch will move reading and writing of PCI configuration
>> spaces from dom0 to Xen. It also changes VTD code, so that they can
>> touch the PCI configuration spaces with proper lock.
>> 
>> This will also benefit MSI support in Xen.
>> Can you give some comments? Thanks!
>> 
>> 
>> The approach is fine. I will read it more thoroughly, clean it up a bit
if
>> necessary, and certainly check it in.
>> 
>> -- Keir
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>> 
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://lists.xensource.com/archives/html/xen-devel/attachments/20080410/263aa734/attachment.htm

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

Actually I do not find a clear explanation in MCH specification on this.
Luckily, dom0''s kernel does not write 0xcf8 without valid bit set.
Does access to 0xCFC return data based on the last valid latched data in 0xCF8,
or last latched data without valid bit set in 0xCF8?
For example:
Outl(0x80000000, 0xcf8);
Outl(0x00000001, 0xcf8);
Inl(0xcfc); <----This is skipped? Or data at 00:00.0 register 0.
Another question is:
Outl(0x80000000, 0xcf8);
Inb(0xcfc);
Inb(0xcfd); <----This is skipped? Or data at 00:00.0 register 1?
Can you tell me where do you find these answers? Thanks!

Shan Haitao

-----Original Message-----
From: Espen Skoglund [mailto:espen.skoglund@netronome.com] 
Sent: 2008年4月11日 0:55
To: Haitao Shan
Cc: Keir Fraser; Shan, Haitao; Tian, Kevin; xen-devel; Kay, Allen M; Jiang,
Yunhong; Han, Weidong
Subject: Re: [Xen-devel] [PATCH][RFC]Move PCI Configuration Spacesfrom Dom0 to
Xen

I believe dword writes to 0xCF8 should always be latched into the
internal shadow register, irrespective of whether the enable bit (bit
31) is set.  Accesseses to 0xCFC can then safely be skipped if enable
bit in latch register is not set.

	eSk



[Haitao Shan]
> Thanks, Keir!
> 2008/4/10, Keir Fraser <keir.fraser@eu.citrix.com>:
>> 
>> On 10/4/08 10:45, "Shan, Haitao"
<haitao.shan@intel.com> wrote:
>> 
>> This patch will move reading and writing of PCI configuration
>> spaces from dom0 to Xen. It also changes VTD code, so that they can
>> touch the PCI configuration spaces with proper lock.
>> 
>> This will also benefit MSI support in Xen.
>> Can you give some comments? Thanks!
>> 
>> 
>> The approach is fine. I will read it more thoroughly, clean it up a bit
if
>> necessary, and certainly check it in.
>> 
>> -- Keir
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>> 
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://lists.xensource.com/archives/html/xen-devel/attachments/20080410/263aa734/attachment.htm

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

I think we can safely follow qemu here and return all-1s on reads when the
enable bit in cf8 is clear. I''ll make that change.

 -- Keir

On 11/4/08 01:42, "Shan, Haitao" <haitao.shan@intel.com> wrote:
> Actually I do not find a clear explanation in MCH specification on this.
> Luckily, dom0''s kernel does not write 0xcf8 without valid bit set.
> Does access to 0xCFC return data based on the last valid latched data in
> 0xCF8, or last latched data without valid bit set in 0xCF8?
> For example:
> Outl(0x80000000, 0xcf8);
> Outl(0x00000001, 0xcf8);
> Inl(0xcfc); <----This is skipped? Or data at 00:00.0 register 0.
> Another question is:
> Outl(0x80000000, 0xcf8);
> Inb(0xcfc);
> Inb(0xcfd); <----This is skipped? Or data at 00:00.0 register 1?
> Can you tell me where do you find these answers? Thanks!
> 
> Shan Haitao
> 
> -----Original Message-----
> From: Espen Skoglund [mailto:espen.skoglund@netronome.com]
> Sent: 2008年4月11日 0:55
> To: Haitao Shan
> Cc: Keir Fraser; Shan, Haitao; Tian, Kevin; xen-devel; Kay, Allen M; Jiang,
> Yunhong; Han, Weidong
> Subject: Re: [Xen-devel] [PATCH][RFC]Move PCI Configuration Spacesfrom Dom0
to
> Xen
> 
> I believe dword writes to 0xCF8 should always be latched into the
> internal shadow register, irrespective of whether the enable bit (bit
> 31) is set.  Accesseses to 0xCFC can then safely be skipped if enable
> bit in latch register is not set.
> 
> eSk
> 
> 
> 
> [Haitao Shan]
>> Thanks, Keir!
>> 2008/4/10, Keir Fraser <keir.fraser@eu.citrix.com>:
>>> 
>>> On 10/4/08 10:45, "Shan, Haitao"
<haitao.shan@intel.com> wrote:
>>> 
>>> This patch will move reading and writing of PCI configuration
>>> spaces from dom0 to Xen. It also changes VTD code, so that they can
>>> touch the PCI configuration spaces with proper lock.
>>> 
>>> This will also benefit MSI support in Xen.
>>> Can you give some comments? Thanks!
>>> 
>>> 
>>> The approach is fine. I will read it more thoroughly, clean it up a
bit if
>>> necessary, and certainly check it in.
>>> 
>>> -- Keir
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>> 
>>> 
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: 
>>
http://lists.xensource.com/archives/html/xen-devel/attachments/20080410/263aa
>> 734/attachment.htm
> 


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

>>> "Shan, Haitao" <haitao.shan@intel.com> 10.04.08
11:45 >>>
>Hi, Keir,
>
>This patch will move reading and writing of PCI configuration spaces
>from dom0 to Xen. It also changes VTD code, so that they can touch the
>PCI configuration spaces with proper lock.
>This will also benefit MSI support in Xen.
>Can you give some comments? Thanks!
> <<pci_conf_xen.patch>> 
I don''t think this is going to do what you want when the kernel is
using
mmconfig, or AMD''s extended register space access method (not to
speak of the hopefully not in wide spread use type 2 access method).

Also I find it a little odd that you allow access to ports cf9...cfb rather
than properly handling namely byte accesses to cf9. Likewise it
doesn''t consider the (albeit unlikely) case of multi-byte accesses to
ports crossing the cf8/cfc boundary.

Jan



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

On 11/4/08 13:08, "Jan Beulich" <jbeulich@novell.com> wrote:
> I don''t think this is going to do what you want when the kernel is
using
> mmconfig, or AMD''s extended register space access method (not to
> speak of the hopefully not in wide spread use type 2 access method).
The aim is to synchronise accesses to the PCI window registers cf8/cfc.
It''s
not to synchronise the PCI config space accesses themselves.
> Also I find it a little odd that you allow access to ports cf9...cfb rather
> than properly handling namely byte accesses to cf9. Likewise it
> doesn''t consider the (albeit unlikely) case of multi-byte accesses
to
> ports crossing the cf8/cfc boundary.
I''ve cleaned this up and basically rewritten the patch. I''ll
be checking it
in this afternoon.

 -- Keir



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

Actually, byte or word accesses in the cf8-cfb range should be passed
through as is.  Only dword accesses to cf8 should be latched into the
config-address register.  The original patch is right in the way it
handles sub-dword accesses.

	eSk


[Jan Beulich]
> Also I find it a little odd that you allow access to ports cf9...cfb
> rather than properly handling namely byte accesses to cf9. Likewise
> it doesn''t consider the (albeit unlikely) case of multi-byte
> accesses to ports crossing the cf8/cfc boundary.






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