This is a pretty simple patch to use the read/write barriers defined in asm/system.h instead of using hardcoded versions in various places throughout Xen. I''ve checked and using asm/system.h generates the same code on my system. I also tested xcs and it seems to work fine. I haven''t tested blktap but again, it''s generating the same code. Right now, wmb() is defined as a NOP on any 386 architecture. Some Intel clones require a non-NOP wmb(). Using asm/system.h ensures we do the right thing. It''s against xen-unstable as of today. Regards, Anthony Liguori Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
On 23 Feb 2005, at 03:38, Anthony Liguori wrote:> This is a pretty simple patch to use the read/write barriers defined > in asm/system.h instead of using hardcoded versions in various places > throughout Xen. > > I''ve checked and using asm/system.h generates the same code on my > system. I also tested xcs and it seems to work fine. I haven''t > tested blktap but again, it''s generating the same code.asm/system.h is a private kernel header so should not be directly included from user space. Inlcuding it may not work for all versions of Linux, or for other architectures. We should probably merge the barrier defs we have scattered in the tools directory into one low-level architectural header that we include everywhere, and extend for x86/64, ia64, and so on.> Right now, wmb() is defined as a NOP on any 386 architecture. Some > Intel clones require a non-NOP wmb(). Using asm/system.h ensures we > do the right thing.Only Centaur clones that have been set up by the kernel to do write combining. Xen does not ever enable write-combining on normal RAM and so a barrier is never required. -- Keir ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Keir Fraser wrote:> > On 23 Feb 2005, at 03:38, Anthony Liguori wrote: > > asm/system.h is a private kernel header so should not be directly > included from user space. Inlcuding it may not work for all versions > of Linux, or for other architectures.Actually, asm/system.h is designed for inclusion in userspace apps (and kernel space). Hence the __KERNEL__ guards around certain sections. It''s used in a few notable userspace apps including glibc and MySQL. That said, Xen should not depend on Linux if it doesn''t have to.> We should probably merge the barrier defs we have scattered in the > tools directory into one low-level architectural header that we > include everywhere, and extend for x86/64, ia64, and so on.Agreed. Any ideas on where it would live? I didn''t see any likely place which is why I used asm/system. io/ring.h seemed the closest fit but that''s not architecture specific.> Only Centaur clones that have been set up by the kernel to do write > combining. Xen does not ever enable write-combining on normal RAM and > so a barrier is never required.Ah, that makes sense. It still would be nice to have the barriers in a single location. Pick a place and I''ll submit a patch. Regards, -- Anthony Liguori anthony@codemonkey.ws ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On 23 Feb 2005, at 07:57, Anthony Liguori wrote:>> We should probably merge the barrier defs we have scattered in the >> tools directory into one low-level architectural header that we >> include everywhere, and extend for x86/64, ia64, and so on. > > Agreed. Any ideas on where it would live? I didn''t see any likely > place which is why I used asm/system. io/ring.h seemed the closest > fit but that''s not architecture specific.I''d rather not further clutter the Xen headers with the defintions. libxc is a utility library used by pretty much all the tools. How about defining the barriers in xc.h? -- Keir ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel