Menu
▾
▴
xen-devel — List for Xen developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(245) |
Nov
(321) |
Dec
(102) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(133) |
Feb
(365) |
Mar
(265) |
Apr
(152) |
May
(127) |
Jun
(205) |
Jul
(515) |
Aug
(449) |
Sep
(485) |
Oct
(553) |
Nov
(740) |
Dec
(640) |
| 2005 |
Jan
(1277) |
Feb
(1154) |
Mar
(1282) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Keir F. <Kei...@cl...> - 2005-03-27 10:57:29
|
On 27 Mar 2005, at 04:34, Ronald G. Minnich wrote: > My issues with the Plan 9 port have all revolved around portability > from > x86 to x86, due to the gcc-isms in the headers. I don't think there are that many gcc-isms, apart from use of PACKED (please correct me if I'm wrong). You can always define that to nothing if you need to - I'd hope that no compiler adds padding since all fields should be naturally aligned. I don't see us moving to a model where we define macros on char arrays anytime soon. :-) But perhaps we could include a script to generate such macros from our structure definitions.... I know Kip Macy iss including our public headers into FreeBSD with -ansi, so we can't be that far from ISO code. -- Keir |
|
From: Keir F. <Kei...@cl...> - 2005-03-27 10:51:19
|
On 27 Mar 2005, at 00:27, David Hopwood wrote: > Keir Fraser wrote: >> On 26 Mar 2005, at 17:31, Jimi Xenidis wrote: >>>>> Few things to note: >>>>> 1) packed is [un]necessary since the ABI will do the right thing >> I prefer to pack things explicitly rather than rely on ABI padding. > > If you use -Wpadded when compiling with gcc then you're not relying on > ABI padding; you're automatically checking that it is not used. That > would seem to be precisely what is required here. If I could specify it on a per-struct basis then it would be perfect. But I do want the normal padding rules to be applied for non-public struct definitions. -- Keir |
|
From: Keir F. <Kei...@cl...> - 2005-03-27 10:49:42
|
> I thought the MTRRs have been set by the BIOS, not Xen. Xen propagates the CPU0 MTRR values to all other CPUs. Not all BIOSes do that properly. Linux does the same, when it is booted natively. > The MTRRs are not set to my satisfaction, that's why I'd like to change > them. Hmmm... can you try changing init_table() in arch/xen/i386/kernel/cpu/mtrr/main.c to initialise the usage_table counts to 1 instead of 0? I think that'll fix it for you and matches how native Linux initialises the table. > Obviously, Linux has code to do that -- under Xen it unfortunately > only sees a subset of the CPUs, though. You need to lock out all other CPU activity while you reprogram MTRRs across all CPUs. Obviously Linux cannot do that unaided if Xen is running underneath it. I think the current approach is the correct one, but I was probably trying to be too clever when defining the interface to Xen -- we'll probably end up dumbing it down, and only allow domain0 to do MTRR updates. We can always define an interface thru domain0 for other driver domains to declare memory types if we feel the need. If you can check that modifying initialisation of usage_table[] fixes your problem, I'll do a cleanup and simplification of the MTRR code. -- Keir |
|
From: Ronald G. M. <rmi...@la...> - 2005-03-27 03:34:36
|
On Sat, 26 Mar 2005, Keir Fraser wrote: > Actually, one of the more interesting thing to discuss imo is how to structure > the public interface headers to support multiple architectures. As the headers are written now, they are not portable across different C compilers, which is a concern to me. If your C compiler doesn't act just like gcc, you're going to have to translate the headers. > Is it feasible to strive for much commonality, or should each arch have > its own public headers, or what? I don't have a good feel for what the > best solution is going to be... It is feasible to strive for commonality, I think. I would prefer headers that make no use of any gcc magic. It is a bit of a problem for me each time xen rotates headers as I have to translate them all over again. My issues with the Plan 9 port have all revolved around portability from x86 to x86, due to the gcc-isms in the headers. ron |
|
From: Brian H. <bri...@gm...> - 2005-03-27 00:29:13
|
nevermind on the below question ... I built an rpm from the e2fsprogs 1.36 src-rpm (from the FC4 test1 SRPMS), installed it in my RH9 filesystem and now it boots up great. Thanks, Brian On Sat, 26 Mar 2005 18:25:08 -0500, Brian Hays <bri...@gm...> wrote: > When trying to start my (redhat9) domU I get the following errors > everytime on boot. I have tried using ext3 and ext2 as the filesystem > type with the same results. Does anyone know what may cause this (see > below) : > > Checking root filesystem > fsck.ext2: [/sbin/fsck.ext2 (1) -- /] fsck.ext2 -a /dev/sda1 > Filesystem has unsupported feature(s) (/dev/sda1) > e2fsck: Get a newer version of e2fsck! > [FAILED] > > *** An error occurred during the file system check. > *** Dropping you to a shell; the system will reboot > *** when you leave the shell. > Give root password for maintenance > (or type Control-D to continue): > > Thank you, > Brian > > On Sat, 26 Mar 2005 09:49:36 -0500, Michael McCabe <mcc...@gm...> wrote: > > Brian > > This article has information about installing Fedora Core 3 as a guest > > using Yum. http://www-128.ibm.com/developerworks/library/l-xen/ . The > > group information isn't available in the version of yum that is > > available for Redhat 9 so you'll have to install packages and have it > > pull in the dependencies. If you need any other help setting up your > > Redhat images let me know, I've been using them extensively in the past > > couple of weeks. > > > > Mike > > > > Brian Hays wrote: > > > > >Hello, > > > > > >What is the best way to create guest (domU) filesystems? I am > > >currently running the latest version on Xen on FC3 and would like to > > >create a Redhat 9 and Fedora Core 1 filesystem for use on domU's. What > > >is the best way to accomplish this, and also ... will Redhat 9 boot on > > >the 2.6.11 kernel (I'm using the xen & kernel-xen0 & U rpms from the > > >FC4test1 repository ... it only comes with 2.6 kernels)? If not how > > >can I add another xenU kernel (2.4 version)? > > > > > >Thank you, > > >Brian > > > > > > > > >------------------------------------------------------- > > >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...@li... > > >https://lists.sourceforge.net/lists/listinfo/xen-devel > > > > > > > > > > > > > > |
|
From: David H. <dav...@bl...> - 2005-03-27 00:28:09
|
Keir Fraser wrote: > On 26 Mar 2005, at 17:31, Jimi Xenidis wrote: > >>>> Few things to note: >>>> 1) packed is [un]necessary since the ABI will do the right thing > > I prefer to pack things explicitly rather than rely on ABI padding. If you use -Wpadded when compiling with gcc then you're not relying on ABI padding; you're automatically checking that it is not used. That would seem to be precisely what is required here. -- David Hopwood <dav...@bl...> |
|
From: Kurt G. <ku...@ga...> - 2005-03-27 00:04:11
|
Hi Keir, On Thu, Mar 24, 2005 at 06:26:44PM +0000, Keir Fraser wrote: > It's been hacked just enough to get X working, but the /proc semantics=20 > haven't been given much thought. The problem is that reading /proc/mtrr= =20 > tells you what the real physical MTRRs contain, but these registers=20 > weren't initialised by domain0 but by Xen, during SMP bootstrap. So=20 > when you attempt to delete them you will probably find error messages=20 > in /var/log/messages saying 'reg1 has count=3D0'. I thought the MTRRs have been set by the BIOS, not Xen. The MTRRs are not set to my satisfaction, that's why I'd like to change them. > There are a few possible fixes, one being to let domain0 get staright=20 > at the MTRRs after it has booted, but this needs great care --=20 > the registers have to be carefully synchronised across all physical=20 > CPUs to avoid memory deadlocks. =20 Obviously, Linux has code to do that -- under Xen it unfortunately only sees a subset of the CPUs, though. Regards, --=20 Kurt Garloff <ku...@ga...> [Koeln, DE] Physics:Plasma modeling <ga...@pl...> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <ga...@su...> [Novell Inc] |
|
From: Mark W. <mar...@cl...> - 2005-03-26 23:26:05
|
It sounds like you haven't enabled driver domain support. If you want to run a kernel in dom0, you'll need support for physical device access and dom0 ops compiled in. The options are in the Xen config menu. You may find it helpful to start from the dom0 default config (somewhere under arch/xen, I can't remember exactly right now - copy it to linux/.config before running menuconfig). Cheers, Mark On Saturday 26 March 2005 23:05, sten wrote: > I'm hung up at building a Xen Linux kernel with, really, any hardware > support. I'm using the Xen source package pulled from the Xen home page, > which pulls 2.6.10 from kernel.org, and when I do a make menuconfig > ARCH=xen, I simply don't see any of the hardware I'm after listed. No > 3c509, no radeon, no e100, nada. My reading of the Xen docs suggest I > should be able to build whatever hardware support I need into the Xen0 > kernel- is this the proper method for providing drivers, or am I missing > the point completely? > > -sten > > > > ------------------------------------------------------- > 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...@li... > https://lists.sourceforge.net/lists/listinfo/xen-devel |
|
From: Brian H. <bri...@gm...> - 2005-03-26 23:25:16
|
When trying to start my (redhat9) domU I get the following errors everytime on boot. I have tried using ext3 and ext2 as the filesystem type with the same results. Does anyone know what may cause this (see below) : Checking root filesystem fsck.ext2: [/sbin/fsck.ext2 (1) -- /] fsck.ext2 -a /dev/sda1 Filesystem has unsupported feature(s) (/dev/sda1) e2fsck: Get a newer version of e2fsck! [FAILED] *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. Give root password for maintenance (or type Control-D to continue): Thank you, Brian On Sat, 26 Mar 2005 09:49:36 -0500, Michael McCabe <mcc...@gm...> wrote: > Brian > This article has information about installing Fedora Core 3 as a guest > using Yum. http://www-128.ibm.com/developerworks/library/l-xen/ . The > group information isn't available in the version of yum that is > available for Redhat 9 so you'll have to install packages and have it > pull in the dependencies. If you need any other help setting up your > Redhat images let me know, I've been using them extensively in the past > couple of weeks. > > Mike > > Brian Hays wrote: > > >Hello, > > > >What is the best way to create guest (domU) filesystems? I am > >currently running the latest version on Xen on FC3 and would like to > >create a Redhat 9 and Fedora Core 1 filesystem for use on domU's. What > >is the best way to accomplish this, and also ... will Redhat 9 boot on > >the 2.6.11 kernel (I'm using the xen & kernel-xen0 & U rpms from the > >FC4test1 repository ... it only comes with 2.6 kernels)? If not how > >can I add another xenU kernel (2.4 version)? > > > >Thank you, > >Brian > > > > > >------------------------------------------------------- > >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...@li... > >https://lists.sourceforge.net/lists/listinfo/xen-devel > > > > > > > > |
|
From: sten <li...@re...> - 2005-03-26 23:08:40
|
I'm hung up at building a Xen Linux kernel with, really, any hardware support. I'm using the Xen source package pulled from the Xen home page, which pulls 2.6.10 from kernel.org, and when I do a make menuconfig ARCH=xen, I simply don't see any of the hardware I'm after listed. No 3c509, no radeon, no e100, nada. My reading of the Xen docs suggest I should be able to build whatever hardware support I need into the Xen0 kernel- is this the proper method for providing drivers, or am I missing the point completely? -sten |
|
From: <ma...@tw...> - 2005-03-26 19:17:29
|
On Fri, Mar 25, 2005 at 03:35:47PM -0600, Anthony Liguori wrote: > Here are the mechanisms I know and their requirements. I plan to put > this in the Wiki as soon as it goes live (if it's not already there): Last "Real Soon Now" I saw was back ont he 10th, and that was an important reason I didn't do this sooner. As of ten minutes ago, a nearly empty Interim Xen Wiki is up and running at http://www.two14.net/xen Access to create or edit pages requires a trivial registration at http://www.two14.net/xen/UserPreferences This is mostly to discourage wiki spam, though I won't be at all unhappy if the official wiki gets setup so quickly that the spammers won't have time to annoy us. OTOH, I don't see any reason this wiki couldn't stay live for as long as it takes, though there might be some disruption when the hardware has to get shuffled. If you register with a working email address - no, of course it isn't actually checked - you can subscribe to get notices when some (or all) pages get updated. FWIW, I spent more time borrowing the logo and hacking up a minimal Xen page with a link to the project and so forth than on the actual wiki setup. Granted, this wasn't the first time I've setup a wiki with Moin on this box. -- I didn't write a whole, free operating system, either. I wrote some pieces and invited other people to join me by writing other pieces. So I set an example. I said, "I'm going in this direction. Join me and we'll get there." And enough people joined in that we got there. -- R M Stallman |
|
From: Magenheimer, D. (HP L. F. Collins) <dan...@hp...> - 2005-03-26 19:00:55
|
When I was at this stage (working through header file issues) of the Xen/ia64 port, I had a long list of minor patches to common files. The core Xen team (Ian and Keir) asked that, wherever possible, I handle ia64 changes _with minimal impact_ to common files/headers. This was annoying as I had to carry a lot of inelegant code in ia64-specific files for a long time. Looking back, however, I think it was the right decision. As the Xen/ia64 code evolved (and eventually ran), many of the common changes I asked for also changed or, in some cases, went away. In the end, there were a small number of patches I needed that were unavoidable. I'd like to suggest that this is also the right approach for new arch's: If something can be made to work with just changes to arch-specific files, even unaesthetic changes, just do it. Then later when Xen/ppc (and perhaps other arch's) are working, we can have a "clean up the common code" fest. In the meantime, minor cosmetic changes that require work both in the core and in other arch's are just keeping us from making real progress on needed functionality and stability. Just my opinion... Dan > -----Original Message----- > From: Christian Limpach [mailto:chr...@gm...]=20 > Sent: Friday, March 25, 2005 7:15 PM > To: Hollis Blanchard > Cc: xen...@li...; Magenheimer, Dan (HP=20 > Labs Fort Collins) > Subject: Re: [Xen-devel] Re: [patch] final header fixes >=20 > On Fri, 25 Mar 2005 10:22:50 -0600, Hollis Blanchard=20 > <ho...@us...> wrote: > > On Thu, 2005-03-24 at 21:24 +0000, Christian Limpach wrote: > > > On Thu, 24 Mar 2005 15:03:19 -0600, Hollis Blanchard=20 > <ho...@us...> wrote: > > > > On Thursday 24 March 2005 14:40, Dan Magenheimer wrote: > > > > > This second patch looks good to me, though I would prefer > > > > > to change to '#include <asm/regs.h>' from 'struct xen_regs;' > > > > > as xen_regs is #define'd to pt_regs on ia64 and the explicit > > > > > use of struct xen_regs in a header could cause header ordering > > > > > problems later. Will that work for ppc? > > > > > > > > Ah, sure... I was just trying to avoid extra dependency=20 > trees where possible. > > > > Apparently it is not possible here. :) > > > > > > > > So that should be #include <public/xen.h> (which=20 > includes arch-*.h which > > > > defines xen_regs). It looks like we may want to move=20 > ia64's #define to > > > > arch-ia64.h ... > > > > > > Could you please include asm/regs.h or public/xen.h=20 > wherever you want > > > to include keyhandler.h? Thanks. > >=20 > > That works great, until somebody other than me includes or modifies > > keyhandler.h (or any of the other headers we've been talking about). > >=20 > > I guess I don't see the difficulty in making sure you=20 > include what you > > use...? >=20 > I think we have too many header files which include other header files > already -- to the point that a lot of .c files don't include all the > header files they need because some random header file includes it for > them. >=20 > keyhandler.c is one of the header files you probably want to include > in source code level add-on software, software which might be require > using a header set which is not compatible with Xen's header set. >=20 > christian >=20 |
|
From: Jimi X. <ji...@wa...> - 2005-03-26 18:47:00
|
>>>>> "KF" == Keir Fraser <Kei...@cl...> writes: KF> On 26 Mar 2005, at 17:49, Keir Fraser wrote: KF> Actually, one of the more interesting thing to discuss imo is how to KF> structure the public interface headers to support multiple KF> architectures. Is it feasible to strive for much commonality, or should KF> each arch have its own public headers, or what? I don't have a good KF> feel for what the best solution is going to be... Considering that on PPC we'll be trying to support domains of several different ABIs (ELF, XCOFF and MachO) not to mention 32 bit apps on 64bit machines, we are extremely sensitive (and sympathetic) to your goals. On x86 you have Windows, and their (intentionally) incompatible 64 bit ABI :( The current use of specific sized types is good for this goal. Typically, defining these data structures with a member order that removes padding, or padding explicitly to disambiguate structure layout, is a good strategy (-Wpadded can help here). I think we will disable PACKED on PPC and see how that goes, as we detect padded areas we will submit patches that may shuffle structure members to achieve the above goals. WRT to subword accesses, we will continue to eveluate them and generate some patches for your approval, rather than attempt to shuffle bits around at runtime. -JX |
|
From: Peter B. <pet...@we...> - 2005-03-26 18:22:30
|
I have installed XEN and linux 2.6.10 on three different machines. The slowest of them was my computer at home running and Athlon XP 1600+ ( 1.4 GHZ ) and 256 MB RAM. My Problem is reduced file-system performance in domU guests. These guest run faster when I use loopbacked files on Dom0 than the do when I use real partitions and poulate them with a linux system. I found out that dom0 does file-system IO and raw IO ( using dd as a tool to test throughput from the disk ) is about exactly the same as when using a standard linux kernel without XEN. But the raw IO from DomU to an unused disk ( a second disk in the system ) is limited to fourty percent of the speed I get within Dom0. This effect transforms to about the same ratio when doing real file-system IO. I found this sympthom in all of the systems I installed. An early paper about XEN describes that the penalty when using VDBs is close to zero and neglectable. I think this conflicts with the results I got and I believe this reflects that something in my configuration is wrong ( at least I hope so ). I have the drivers for my chipset linked into the kernel and hdparm tells me that DMA is enabled for the used disks ( using hdparm under Dom0 ). What worries me is that the results within Dom0 are completely satisfactory, while those in DomU are not. Do I have to change the kernel config for DomU ? Or is there any special option I have to set in the kernel configuration for Dom0 or even for xen? I have compiled version 2.0.5 - the newest available, to my knowledge. Any hints ?? |
|
From: Keir F. <Kei...@cl...> - 2005-03-26 17:57:26
|
On 26 Mar 2005, at 17:49, Keir Fraser wrote: > I prefer to pack things explicitly rather than rely on ABI padding. My > aim is to be able to document the interfaces separately from the C > source, and that will include knowing the offset of each field, and > that's easiest if the compiler isn't automatically helping by paddin > things unexpectedly. If PACKED is too painful on a particular arch you > can always stub it out -- it's only a macro after all. Actually, one of the more interesting thing to discuss imo is how to structure the public interface headers to support multiple architectures. Is it feasible to strive for much commonality, or should each arch have its own public headers, or what? I don't have a good feel for what the best solution is going to be... -- Keir |
|
From: Keir F. <Kei...@cl...> - 2005-03-26 17:50:39
|
On 26 Mar 2005, at 17:31, Jimi Xenidis wrote: >>>>>> "RGM" == Ronald G Minnich <rmi...@la...> writes: > > RGM> On Fri, 25 Mar 2005, Jimi Xenidis wrote: > >>> Few things to note: >>> 1) packed is necessary since the ABI will do the right thing > RGM> un-necessary? > oops, yes un-necessary. > -JX I prefer to pack things explicitly rather than rely on ABI padding. My aim is to be able to document the interfaces separately from the C source, and that will include knowing the offset of each field, and that's easiest if the compiler isn't automatically helping by paddin things unexpectedly. If PACKED is too painful on a particular arch you can always stub it out -- it's only a macro after all. -- Keir |
|
From: Ronald G. M. <rmi...@la...> - 2005-03-26 17:36:34
|
On Sat, 26 Mar 2005, Jimi Xenidis wrote: > Could we not simply avoid *subword* accesses in common code as a rule? > It costs x86 nothing to do this and results in portable code. it would help me too ... ron |
|
From: Jimi X. <ji...@wa...> - 2005-03-26 17:32:03
|
>>>>> "RGM" == Ronald G Minnich <rmi...@la...> writes: RGM> On Fri, 25 Mar 2005, Jimi Xenidis wrote: >> Few things to note: >> 1) packed is necessary since the ABI will do the right thing RGM> un-necessary? oops, yes un-necessary. -JX |
|
From: Ronald G. M. <rmi...@la...> - 2005-03-26 17:29:49
|
On Fri, 25 Mar 2005, Jimi Xenidis wrote:
> Few things to note:
> 1) packed is necessary since the ABI will do the right thing
un-necessary?
ron
|
|
From: Keir F. <Kei...@cl...> - 2005-03-26 17:08:39
|
On 26 Mar 2005, at 14:13, Jimi Xenidis wrote: > KF> We always naturally align fields, even in packed structs. The > compiler > KF> doesn't do it for us, but we check it manually. > > hmm, is it padding you are trying to avoid? > Perhaps not using packed and adding the gcc option '-Wpadded' which > will automagically catch the offenders for you might be more > appropriate? > > Depending on manually checking can result in performance and > correctness issues that are difficult to track. Mostly it's used for structs that are part of the public Xen interface. I don't want different compilers packing fields in different ways. -- Keir |
|
From: Erik de B. - BudgetDedicated.c. <Er...@Bu...> - 2005-03-26 16:14:34
|
Dear developers,
We are unable to start xend after it hung and we decided to kill it. We
are using a 2.0.5 version xen tree (built from source).
When issuing a xend start the xend-debug.log contains the following
traceback:
...
d = vm.construct(config)
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 453, in
construct self.construct_image()
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 480, in
construct_image image_handler(self, image)
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 1065, in
vm_image_linux vm.create_domain("linux", kernel, ramdisk, cmdline)
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 757, in
create_domain self.create_channel()
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 782, in
create_channel remote_port=remote)
File "/usr/lib/python/xen/xend/server/SrvDaemon.py", line 660, in
createDomChannel remote_port=remote_port)
File "/usr/lib/python/xen/xend/server/channel.py", line 59, in
domChannel remote_port=remote_port)
File "/usr/lib/python/xen/xend/server/channel.py", line 229, in
__init__ remote_port=remote_port)
File "/usr/lib/python/xen/xend/server/channel.py", line 113, in
createPort remote_port=int(remote_port))
xen.lowlevel.xu.PortError: Failed to map domain control interface
We've already duplicated the entire system to another host which runs
xend fine. We assume that it will start to work after a reboot. However
a reboot is not an option on this production system. There are no ports
bound near 8000 (+) or 96xx. We've tried to run xend on an different
port (changing /etc/xen/xend-config.sxp to: (xend-port 8500))
but that yeilded no better result. We've also tried binding it to
0.0.0.0, localhost and 127.0.0.1.
xfrd does succesfully start:
tcp 0 0 0.0.0.0:8002 0.0.0.0:*
LISTEN 13420/xfrd
Where can we look to fix this problem without having to reboot, and
without encountering the same problem again? Browsing the source-code
didn't give me any pointers yet. Please tell me if more information
would be helpful and what info that would be.
--
Kind regards,
Erik de Bruijn
BudgetDedicated
www.BudgetDedicated.com | Tel. +31 13 4690625 | Fax. +31 84 2248796 | Mob. +31 6 21856715 | Adres: Adelaarshorst 9 | Zipcode NL-5042 XE Tilburg
|
|
From: Jimi X. <ji...@wa...> - 2005-03-26 14:13:22
|
>>>>> "KF" == Keir Fraser <Kei...@cl...> writes:
KF> On 25 Mar 2005, at 23:49, Jimi Xenidis wrote:
>> A few issues:
>> 1) this assumes that the quantity is wholy contained in our atomic
>> unit, by using packed there is no way to guarantee that.
KF> We always naturally align fields, even in packed structs. The compiler
KF> doesn't do it for us, but we check it manually.
hmm, is it padding you are trying to avoid?
Perhaps not using packed and adding the gcc option '-Wpadded' which
will automagically catch the offenders for you might be more
appropriate?
Depending on manually checking can result in performance and
correctness issues that are difficult to track.
>> 2) it would have to be a runtime decision on all PPC atomic
>> operations that could fail with no real failure path available.
KF> It may have to be a run-time decision unless we can come up with some
KF> clever trick. I don't understand what you mean about there being no
KF> failure path.
These are atomic operation, usually used in contexts where printing or
any other feedback is unavailable.
KF> This may make sense since we do update those two fields as a pair. We
KF> have a big update to the grant table code about to be checked in. We
KF> shoudl hold off doing this kind of fix until after the update has been
KF> committed.
Agreed, its not like I'm even at the point of running this code :)
However, some attention to endianness would also be appreciated,
example common/grant_table.c:870 (and friends)
/* Merge two 16-bit values into a 32-bit combined update. */
/* NB. Endianness! */
prev_scombo = scombo = ((u32)sdom << 16) | (u32)sflags;
KF> We always naturally align fields. We may do *subword* accesses
KF> sometimes, but they are always naturally aligned and will never
KF> straddle a cacheline. I think that subword accesses should get fixed up
KF> in your ppc macros.
Could we not simply avoid *subword* accesses in common code as a rule?
It costs x86 nothing to do this and results in portable code.
|
|
From: Christian L. <chr...@gm...> - 2005-03-26 02:15:03
|
On Fri, 25 Mar 2005 10:22:50 -0600, Hollis Blanchard <ho...@us...> wrote:
> On Thu, 2005-03-24 at 21:24 +0000, Christian Limpach wrote:
> > On Thu, 24 Mar 2005 15:03:19 -0600, Hollis Blanchard <ho...@us...> wrote:
> > > On Thursday 24 March 2005 14:40, Dan Magenheimer wrote:
> > > > This second patch looks good to me, though I would prefer
> > > > to change to '#include <asm/regs.h>' from 'struct xen_regs;'
> > > > as xen_regs is #define'd to pt_regs on ia64 and the explicit
> > > > use of struct xen_regs in a header could cause header ordering
> > > > problems later. Will that work for ppc?
> > >
> > > Ah, sure... I was just trying to avoid extra dependency trees where possible.
> > > Apparently it is not possible here. :)
> > >
> > > So that should be #include <public/xen.h> (which includes arch-*.h which
> > > defines xen_regs). It looks like we may want to move ia64's #define to
> > > arch-ia64.h ...
> >
> > Could you please include asm/regs.h or public/xen.h wherever you want
> > to include keyhandler.h? Thanks.
>
> That works great, until somebody other than me includes or modifies
> keyhandler.h (or any of the other headers we've been talking about).
>
> I guess I don't see the difficulty in making sure you include what you
> use...?
I think we have too many header files which include other header files
already -- to the point that a lot of .c files don't include all the
header files they need because some random header file includes it for
them.
keyhandler.c is one of the header files you probably want to include
in source code level add-on software, software which might be require
using a header set which is not compatible with Xen's header set.
christian
|
|
From: Keir F. <Kei...@cl...> - 2005-03-25 23:59:44
|
On 25 Mar 2005, at 23:49, Jimi Xenidis wrote:
>>>>>> "KF" == Keir Fraser <Kei...@cl...> writes:
>
> KF> I expect we can fix that up in the ppc macros: if the atomic
> access is
> KF> sub-32-bit aligned then round the address down to 32-bit boundary
> and
> KF> do a 32-bit cmpxchg.
>
> A few issues:
> 1) this assumes that the quantity is wholy contained in our atomic
> unit, by using packed there is no way to guarantee that.
We always naturally align fields, even in packed structs. The compiler
doesn't do it for us, but we check it manually.
> 2) it would have to be a runtime decision on all PPC atomic
> operations that could fail with no real failure path available.
It may have to be a run-time decision unless we can come up with some
clever trick. I don't understand what you mean about there being no
failure path.
> We could also program it out, consider this alternative:
> typedef struct {
> struct {
> u16 flags; /* 0 */
> domid_t domid; /* 2 */
> } atomic;
> u32 frame; /* 4 */
> } grant_entry_t; /* 8 bytes */
This may make sense since we do update those two fields as a pair. We
have a big update to the grant table code about to be checked in. We
shoudl hold off doing this kind of fix until after the update has been
committed.
> Few things to note:
> 1) packed is necessary since the ABI will do the right thing
> 2) would simplify the code at grant_table.c:162
> 3) will have better performance since all access are guranteed to be
> aligned.
We always naturally align fields. We may do *subword* accesses
sometimes, but they are always naturally aligned and will never
straddle a cacheline. I think that subword accesses should get fixed up
in your ppc macros. In teh specific case of the grant table structures
let's look closer once teh big update is in the tree.
-- Keir
|
|
From: Jimi X. <ji...@wa...> - 2005-03-25 23:49:32
|
>>>>> "KF" == Keir Fraser <Kei...@cl...> writes:
KF> I expect we can fix that up in the ppc macros: if the atomic access is
KF> sub-32-bit aligned then round the address down to 32-bit boundary and
KF> do a 32-bit cmpxchg.
A few issues:
1) this assumes that the quantity is wholy contained in our atomic
unit, by using packed there is no way to guarantee that.
2) it would have to be a runtime decision on all PPC atomic
operations that could fail with no real failure path available.
We could also program it out, consider this alternative:
typedef struct {
struct {
u16 flags; /* 0 */
domid_t domid; /* 2 */
} atomic;
u32 frame; /* 4 */
} grant_entry_t; /* 8 bytes */
Few things to note:
1) packed is necessary since the ABI will do the right thing
2) would simplify the code at grant_table.c:162
3) will have better performance since all access are guranteed to be
aligned.
I understand the usefulness of packed, but its gratuitous use
unecessarily complicates other architectures, and can hurt even x86 if
it results in a data that "straddles" cachelines.
-JX
|
55 messages has been excluded from this view by a project administrator.
