[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH][RFC]Move PCI Configuration Spacesfrom Dom0 to Xen
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@xxxxxxxxx> 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@xxxxxxxxxxxxx] > 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@xxxxxxxxxxxxx>: >>> >>> On 10/4/08 10:45, "Shan, Haitao" <haitao.shan@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |