Now that Xen has platform code has been upgraded to be based off of the LK 2.6 code base, it seems that the best way of introducing other platform specific code would be to add "genapic" support. Is anybody working on this? Is the unstable tree ready for this? Aravindh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 17 May 2005, at 22:18, Puthiyaparambil, Aravindh wrote:> Now that Xen has platform code has been upgraded to be based off of the > LK 2.6 code base, it seems that the best way of introducing other > platform specific code would be to add "genapic" support. Is anybody > working on this? Is the unstable tree ready for this?I''m not sure what ''genapic'' support is, but if you mean porting things like mach-es7000 across to Xen, then yes: I think we are now ready for that. Longer term I''d like to make switching between the different mach types a run-time rather than compile-time decision. But that will require a fair bit of modification to the standard Linux way of doing things -- for initial 3.0 I think we''ll stick to compile-time switches for selecting esoteric platform configurations. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:> On 17 May 2005, at 22:18, Puthiyaparambil, Aravindh wrote: > >> Now that Xen has platform code has been upgraded to be based off of the >> LK 2.6 code base, it seems that the best way of introducing other >> platform specific code would be to add "genapic" support. Is anybody >> working on this? Is the unstable tree ready for this? > > I''m not sure what ''genapic'' support is, but if you mean porting things > like mach-es7000 across to Xen, then yes: I think we are now ready for > that. > > Longer term I''d like to make switching between the different mach types a run-time rather than compile-time decision. But that will require a fair bit of modification to the standard Linux way of doing things -- > for initial 3.0 I think we''ll stick to compile-time switches for > selecting esoteric platform configurations.genapic is exactly what you''re describing - runtime switching of subarchitectures. It is done in the "generic" i386 subarchitecture with some preprocessor hacks. It''s called genapic because it only tries to handle APIC differences, not other very un PC like architectures like visws or Voyager who have many other differences too. The common setups (Summit, es7000, big xapic, flat apic) don''t need much more. Using compile time switches for 3.0 would make it unusable for distributions who likely won''t ship different binaries for the different low level architectures and force them to do genapic like hacks on their own. Better probably to do it right from the beginning, it is not that hard if you take a look at the Linux code. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Genapic loosely refers to the generic sub architecture for i386 and x86_64 platforms though it is implemented differently for the two. It makes switching between different mach types a run-time option. This is what Andi Kleen had to say about it when he submitted the patch to the LK. [PATCH] generic subarchitecture for ia32 From: Andi Kleen <ak@muc.de> This patch adds an generic x86 subarchitecture. It is intended to provide an dynamic interface for APIC drivers. There are already three subarchitectures (bigsmp, summit, default) that only differ in how they drive the local APIC. A fourth - Unisys ES7000 - is scheduled to be merged soon. The subarchitecture concept separated this nicely, but it has the big drawback that they are compile time options. A Linux vendor cannot ship own binary kernel rpms for all of these machines. Runtime probing is needed instead. This patch adds a new "generic" subarchitecture that just acts as a dynamic switching layer for APIC drivers. It only tries to virtualize the APICs, no attempt is made to cover further incompatiblities. This means machines like the Visual Workstation, pc9800 or Voyager are not covered; but these are unlikely to be supported by binary distributions anyways. The generic arch reuses the existing interface in mach_ipi / mach_mpparse.h / mach_apic.h and just pulls it using some macros into an "struct genapic" object. The main APIC code does not recognize it, it is all hidden in the mach-generic include files. Auto detection of APIC types is supported in the usual way used by existing ports like Summit - checking ACPI or mptables for specific signatures - or it can be specified by the user using a new "apic=" boot option. I also moved the DMI scan to before the generic subarchitecture probe, so DMI could be used in future too to probe specific machines. Some minor hacks were needed to avoid circular declaration of a few symbols, but overall it''s fairly clean. The patch has been tested on a Summit machine, an generic 4 virtual CPUs Xeon and on an ES7000. But for now I shall bring in the mach-es7000 as a compile time option. Aravindh -----Original Message----- From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] Sent: Wednesday, May 18, 2005 3:34 AM To: Puthiyaparambil, Aravindh Cc: xen-devel@lists.xensource.com; Vessey, Bruce A; Subrahmanian, Raj Subject: Re: [Xen-devel] Genapic On 17 May 2005, at 22:18, Puthiyaparambil, Aravindh wrote:> Now that Xen has platform code has been upgraded to be based off ofthe> LK 2.6 code base, it seems that the best way of introducing other > platform specific code would be to add "genapic" support. Is anybody > working on this? Is the unstable tree ready for this?I''m not sure what ''genapic'' support is, but if you mean porting things like mach-es7000 across to Xen, then yes: I think we are now ready for that. Longer term I''d like to make switching between the different mach types a run-time rather than compile-time decision. But that will require a fair bit of modification to the standard Linux way of doing things -- for initial 3.0 I think we''ll stick to compile-time switches for selecting esoteric platform configurations. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18 May 2005, at 14:57, Andi Kleen wrote:> Using compile time switches for 3.0 would make it unusable for > distributions who likely won''t ship different binaries for > the different low level architectures and force them to do > genapic like hacks on their own. Better probably to do it right > from the beginning, it is not that hard if you take a look > at the Linux code.I see that the ones you say can be run-time switched all add include/asm/mach-default to the include search path as normal, and then presumably explicitly include <asm/mach-xxx/xxx.h> where required. Those that replace mach-default with their own include directory in the search path presumably are forced to be a compile-time option? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18 May 2005, at 14:59, Puthiyaparambil, Aravindh wrote:> But for now I shall bring in the mach-es7000 as a compile time option.I didn''t realise that most of the genapic targets are trivially run-time selectable. That being the case, I''m happy for you to make es7000 run-time selected right now. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18 May 2005, at 16:23, Keir Fraser wrote:>> Using compile time switches for 3.0 would make it unusable for >> distributions who likely won''t ship different binaries for >> the different low level architectures and force them to do >> genapic like hacks on their own. Better probably to do it right >> from the beginning, it is not that hard if you take a look >> at the Linux code. > > I see that the ones you say can be run-time switched all add > include/asm/mach-default to the include search path as normal, and > then presumably explicitly include <asm/mach-xxx/xxx.h> where > required. Those that replace mach-default with their own include > directory in the search path presumably are forced to be a > compile-time option?Ah, the penny drops. genapic is selected by pointing at mach-generic directories. That certainly looks like it should port over to Xen with little difficulty. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Genapic is done differently for i386 and x86_64 in the LK. In i386 it is machine specific and in x86_64 it is APIC model specific. Do you want Xen to mimic that? Further more both i386 and x86_64 have separate apic.c, io_apic.c (just to name a couple) files. Xen shares them between the two. Will that cause any problems? I am wondering if it is possible to have a unified genapic for Xen. Or is it way too complicated? Aravindh -----Original Message----- From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] Sent: Wednesday, May 18, 2005 11:25 AM To: Puthiyaparambil, Aravindh Cc: Davis, Jason; xen-devel@lists.xensource.com; Vessey, Bruce A; Subrahmanian, Raj Subject: Re: [Xen-devel] Genapic On 18 May 2005, at 14:59, Puthiyaparambil, Aravindh wrote:> But for now I shall bring in the mach-es7000 as a compile time option.I didn''t realise that most of the genapic targets are trivially run-time selectable. That being the case, I''m happy for you to make es7000 run-time selected right now. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, May 18, 2005 at 11:45:20AM -0400, Puthiyaparambil, Aravindh wrote:> Genapic is done differently for i386 and x86_64 in the LK. In i386 it is > machine specific and in x86_64 it is APIC model specific. Do you want > Xen to mimic that? Further more both i386 and x86_64 have separateThe x86-64 model is better.> apic.c, io_apic.c (just to name a couple) files. Xen shares them between > the two. Will that cause any problems? > > I am wondering if it is possible to have a unified genapic for Xen. Or > is it way too complicated?I hope the plan is to still integrate xen support into arch/i386 and arch/x86_64. Then the problem won''t occur. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18 May 2005, at 16:45, Puthiyaparambil, Aravindh wrote:> Genapic is done differently for i386 and x86_64 in the LK. In i386 it > is > machine specific and in x86_64 it is APIC model specific. Do you want > Xen to mimic that? Further more both i386 and x86_64 have separate > apic.c, io_apic.c (just to name a couple) files. Xen shares them > between > the two. Will that cause any problems? > > I am wondering if it is possible to have a unified genapic for Xen. Or > is it way too complicated?Shared platform code (apics and the like) has been remarkably simple. This is to be expected: processor differences aside, i386 and x86/64 are identical platforms. So, for example, fixing Xen''s smpboot.c (derived from Linux/i386) for x86/64 required one or two lines to be changed. Same for ACPI parsing, MP-table parsing, and so on. I wonder why i386 and x86/64 have been allowed to diverge so wildly in Linux? :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Shared platform code (apics and the like) has been remarkably simple. > This is to be expected: processor differences aside, i386 and x86/64 > are identical platforms. So, for example, fixing Xen''s smpboot.cNo, they are not. x86-64 is a vastly simplified "modern x86 only with minimal bugs" platform, while i386 is a "workarounds for every bug under the sun and all ancient features plus some non PC architectures" mixed bag of stuff. This leads to many differences in details. One bigger difference is that x86-64 is also normally NUMA enabled, while i386 normally is not. There are some others too. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Andi Kleen wrote:>> Shared platform code (apics and the like) has been remarkably simple. >> This is to be expected: processor differences aside, i386 and x86/64 >> are identical platforms. So, for example, fixing Xen''s smpboot.c > > No, they are not. x86-64 is a vastly simplified "modern x86 only with > minimal bugs" platform, while i386 is a "workarounds for every bug > under the sun and all ancient features plus some non PC architectures" > mixed bag of stuff. This leads to many differences in details. > > One bigger difference is that x86-64 is also normally NUMA enabled, > while i386 normally is not. There are some others too. > > -Andi >I think in the long-term we want to have a unified code for pic.c/io_apic.c in XenLinux, but we don''t want to redo the dubugging and testing that have already been done by Linux side (I know it''s very painful). We also want the same platform support in XenLinux as the native Linux does; if we unify them today, we probably lose some machines. This leads us to separate apic.c/io_apic.c for x86 and x86-64 XenLinux (that''s the current plan), because debugging on various platforms is more painful (even not realistic) than maintaining the different code for x86 and x86-64 at this point. Jun> > _______________________________________________ > 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 am a little confused here. When you say XenLinux I am assuming you are talking about the Linux user kernels which have Xen patches. Why would we even turn on the mach specific features in the user kernels? I would think that that the mach specific code needs to reside in the Xen hypervisor itself. It at the moment has unified apic.c/io_apic.c for x86_32 and x86_64 platforms. Don''t we to add genapic code in there? Or am I wrong on this? Maybe I need more coffee :-) Aravindh -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Nakajima, Jun Sent: Wednesday, May 18, 2005 1:22 PM To: Andi Kleen; Keir Fraser Cc: Subrahmanian, Raj; Davis, Jason; xen-devel@lists.xensource.com; Vessey, Bruce A Subject: RE: [Xen-devel] Genapic Andi Kleen wrote:>> Shared platform code (apics and the like) has been remarkably simple. >> This is to be expected: processor differences aside, i386 and x86/64 >> are identical platforms. So, for example, fixing Xen''s smpboot.c > > No, they are not. x86-64 is a vastly simplified "modern x86 only with > minimal bugs" platform, while i386 is a "workarounds for every bug > under the sun and all ancient features plus some non PC architectures" > mixed bag of stuff. This leads to many differences in details. > > One bigger difference is that x86-64 is also normally NUMA enabled, > while i386 normally is not. There are some others too. > > -Andi >I think in the long-term we want to have a unified code for pic.c/io_apic.c in XenLinux, but we don''t want to redo the dubugging and testing that have already been done by Linux side (I know it''s very painful). We also want the same platform support in XenLinux as the native Linux does; if we unify them today, we probably lose some machines. This leads us to separate apic.c/io_apic.c for x86 and x86-64 XenLinux (that''s the current plan), because debugging on various platforms is more painful (even not realistic) than maintaining the different code for x86 and x86-64 at this point. Jun> > _______________________________________________ > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Puthiyaparambil, Aravindh wrote:> I am a little confused here. When you say XenLinux I am assuming you > are talking about the Linux user kernels which have Xen patches. Why > would we even turn on the mach specific features in the user kernels? >Xen assumes particular mach specific featurs, such as timer, memory reporting, IRQ, interrutp handling, which don''t necessarily work with such mach specific features as found on real machines.> I would think that that the mach specific code needs to reside in the > Xen hypervisor itself. It at the moment has unified apic.c/io_apic.c > for x86_32 and x86_64 platforms. Don''t we to add genapic code in > there? Or am I wrong on this? Maybe I need more coffee :-)I talked about the generic platform support, not genapic per se. We have moved ACPI, PCI, and part of io_apic (which required apic.c) handling to dom0 to do better platform detection and configuration. Xen still owns IO APICs, and some operatons must be done by Xen. Jun> > Aravindh >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Based upon the discussion so far, I think this is where xen stands: Xen is currently based upon linux-i386 code, including support for mach-specific functionality in asm-x86/mach-xxx subdirs. Xen is responsible for initializing local APICs and so it must include support for these machines (it can''t be deferred to linux). Linux (dom 0) may or may not need to include support for these machines as well depending upon other features (timers? numa?) which may be added in the future. This is not an issue for Xen 3.0 Adding genapic support to Xen a la linux-i386 should be trivial given the current state of the code. [Genapic allows the appropriate mach-xxx code to be chosen during run time. This is considered very important from a distro stand point] Linux-x86-64 code is very different from i386 from a code organization standpoint. Using apic as an example, it chooses between flat or clustered rather than es7000 vs summit vs xxx. The question is where to go from here to enable Xen to run on sub-arch machines. Given the impending move to Xen 3.0, I think it would be best to pull in the needed Linux-i386 genapic code near-term. This code may very well not be sufficient for newer x86-64 machines Personally, I don''t know. I also don''t know if the x86-64 code can be easily ported to work on the i386 machines currently being targeted. If it can then a move to the x86-64 style may be a good move for the future. Or maybe we need to find a way for both to coexist within Xen. I see this as a post-Xen 3.0 discussion. Does this sound like a viable way forward? Or have I missed something? -Natasha On Wed, 18 May 2005 17:54:43 +0100, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> > On 18 May 2005, at 16:45, Puthiyaparambil, Aravindh wrote: > >> Genapic is done differently for i386 and x86_64 in the LK. In i386 it is >> machine specific and in x86_64 it is APIC model specific. Do you want >> Xen to mimic that? Further more both i386 and x86_64 have separate >> apic.c, io_apic.c (just to name a couple) files. Xen shares them between >> the two. Will that cause any problems? >> >> I am wondering if it is possible to have a unified genapic for Xen. Or >> is it way too complicated? > > Shared platform code (apics and the like) has been remarkably simple. > This is to be expected: processor differences aside, i386 and x86/64 > are identical platforms. So, for example, fixing Xen''s smpboot.c > (derived from Linux/i386) for x86/64 required one or two lines to be > changed. Same for ACPI parsing, MP-table parsing, and so on. I wonder > why i386 and x86/64 have been allowed to diverge so wildly in Linux? :-) > > -- Keir_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Natasha, thanks for bringing order back to the discussion :-)> The question is where to go from here to enable Xen to run on sub-arch> machines. Given the impending move to Xen 3.0, I think it would be > best to pull in the needed Linux-i386 genapic code near-term.I agree that this is the best direction to follow.> This code may very well not be sufficient for newer x86-64 machinesYes, I think this is true.> Personally, I don''t know. I also don''t know if the x86-64 code can be> easily ported to work on the i386 machines currently being targeted. > If it can then a move to the x86-64 style may be a good move for the > future. Or maybe we need to find a way for both to coexist withinXen. We have a few options for getting both i386 and x86_64 genapics working in Xen: 1. Merging the two genapic models into one unified model. This will be a sizeable effort and so is feasible only post Xen 3.0. 2. Create a x86_64 sub-architecture for i386 genapic. But I am not sure how much work will be involved or if this is the best direction to follow. 3. Mimic the Linux kernel and have separate genapic models.> Does this sound like a viable way forward? Or have I missedsomething? For the moment I think it is best we follow Natasha''s suggestion and work towards bringing in the i386 genapic mode. Comments? Aravindh> > > On Wed, 18 May 2005 17:54:43 +0100, Keir Fraser<Keir.Fraser@cl.cam.ac.uk>> wrote: > > > > > On 18 May 2005, at 16:45, Puthiyaparambil, Aravindh wrote: > > > >> Genapic is done differently for i386 and x86_64 in the LK. In i386it> is > >> machine specific and in x86_64 it is APIC model specific. Do youwant> >> Xen to mimic that? Further more both i386 and x86_64 have separate > >> apic.c, io_apic.c (just to name a couple) files. Xen shares them > between > >> the two. Will that cause any problems? > >> > >> I am wondering if it is possible to have a unified genapic for Xen.Or> >> is it way too complicated? > > > > Shared platform code (apics and the like) has been remarkablysimple.> > This is to be expected: processor differences aside, i386 andx86/64> > are identical platforms. So, for example, fixing Xen''s smpboot.c > > (derived from Linux/i386) for x86/64 required one or two lines to be > > changed. Same for ACPI parsing, MP-table parsing, and so on. Iwonder> > why i386 and x86/64 have been allowed to diverge so wildly in Linux?:-)> > > > -- Keir_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, May 18, 2005 at 02:45:49PM -0500, Natasha Jarymowycz wrote:> Based upon the discussion so far, I think this is where xen stands: > > Xen is currently based upon linux-i386 code, including support for > mach-specific functionality in asm-x86/mach-xxx subdirs. > > Xen is responsible for initializing local APICs and so it must include > support for these machines (it can''t be deferred to linux). > > Linux (dom 0) may or may not need to include support for these machines > as well depending upon other features (timers? numa?) which may be > added in the future. This is not an issue for Xen 3.0 > > Adding genapic support to Xen a la linux-i386 should be trivial given > the current state of the code. [Genapic allows the appropriate mach-xxx > code to be chosen during run time. This is considered very important > from a distro stand point] > > Linux-x86-64 code is very different from i386 from a code organization > standpoint. Using apic as an example, it chooses between flat or > clustered rather than es7000 vs summit vs xxx.The behaviour is basically the same. The reason i386 is so different has more historical reasons and that it supports subarchitectures for non PC like x86 systems that need much more changes (like NUMAQ or pc98). genapic actually doesnt support these, but the i386 subarchitectures had to be still fit into that framework. I doubt Xen will ever run on any of these. On x86-64 only the APIC differences are abstracted this way, which is enough for all PC Like systems (including Summit and ES7000) For Xen I would recommend to go with the simpler model from x86-64.> > sub-arch machines. Given the impending move to Xen 3.0, I think it would > be best to pull in the needed Linux-i386 genapic code near-term. > This code may very well not be sufficient for newer x86-64 machinesIt should, but the x86-64 code is much cleaner and should be sufficient.> Personally, I don''t know. I also don''t know if the x86-64 code can be > easily ported to work on the i386 machines currently being targeted.It should. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, May 19, 2005 at 05:10:02PM -0400, Puthiyaparambil, Aravindh wrote:> For the moment I think it is best we follow Natasha''s suggestion and > work towards bringing in the i386 genapic mode. > > Comments?(as having written i386 genapic originally) All this would get you is much historical cruft that Xen really doesnt need. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I am fine with going down the x86_64 genapic route for Xen. The only thing is that I know that IRQ overrides are not present in the x86_64 genapic. So that might have to be brought over for the ES7000. I would like to start working on bringing the x86_64 code over. Will this clash with anyone else? Aravindh -----Original Message----- From: Andi Kleen [mailto:ak@muc.de] Sent: Friday, May 20, 2005 3:03 PM To: Natasha Jarymowycz Cc: Keir Fraser; Puthiyaparambil, Aravindh; xen-devel@lists.xensource.com; Davis, Jason; Vessey, Bruce A; Subrahmanian, Raj Subject: Re: [Xen-devel] Genapic On Wed, May 18, 2005 at 02:45:49PM -0500, Natasha Jarymowycz wrote:> Based upon the discussion so far, I think this is where xen stands: > > Xen is currently based upon linux-i386 code, including support for > mach-specific functionality in asm-x86/mach-xxx subdirs. > > Xen is responsible for initializing local APICs and so it must include > support for these machines (it can''t be deferred to linux). > > Linux (dom 0) may or may not need to include support for thesemachines> as well depending upon other features (timers? numa?) which may be > added in the future. This is not an issue for Xen 3.0 > > Adding genapic support to Xen a la linux-i386 should be trivial given > the current state of the code. [Genapic allows the appropriatemach-xxx> code to be chosen during run time. This is considered very important > from a distro stand point] > > Linux-x86-64 code is very different from i386 from a code organization > standpoint. Using apic as an example, it chooses between flat or > clustered rather than es7000 vs summit vs xxx.The behaviour is basically the same. The reason i386 is so different has more historical reasons and that it supports subarchitectures for non PC like x86 systems that need much more changes (like NUMAQ or pc98). genapic actually doesnt support these, but the i386 subarchitectures had to be still fit into that framework. I doubt Xen will ever run on any of these. On x86-64 only the APIC differences are abstracted this way, which is enough for all PC Like systems (including Summit and ES7000) For Xen I would recommend to go with the simpler model from x86-64.> > sub-arch machines. Given the impending move to Xen 3.0, I think itwould> be best to pull in the needed Linux-i386 genapic code near-term. > This code may very well not be sufficient for newer x86-64 machinesIt should, but the x86-64 code is much cleaner and should be sufficient.> Personally, I don''t know. I also don''t know if the x86-64 code can be > easily ported to work on the i386 machines currently being targeted.It should. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 24 May 2005, at 20:58, Puthiyaparambil, Aravindh wrote:> I am fine with going down the x86_64 genapic route for Xen. The only > thing is that I know that IRQ overrides are not present in the x86_64 > genapic. So that might have to be brought over for the ES7000. > > I would like to start working on bringing the x86_64 code over. Will > this clash with anyone else?I''m about halfway through bringing i386 platform code over. I''m working on smp bootup and cpumask_t right now, but genapic is next and should be quite simple. I''d rather take the more flexible i386 code in the first instance (which will immediately support es7000, for example) and then browse around for nicer bits and pieces from x86/64 (e.g., the IPI code is neat). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, May 24, 2005 at 03:58:56PM -0400, Puthiyaparambil, Aravindh wrote:> I am fine with going down the x86_64 genapic route for Xen. The only > thing is that I know that IRQ overrides are not present in the x86_64 > genapic. So that might have to be brought over for the ES7000.AFAIK an es7000 with EM64T CPUs works on x86-64. So it is probably not needed if you would follow what a real Linux kernel is doing. But of course most of the hypervisor codebase is still 2.4-sometime-ancient so you might run into many more problems there. I suspect they are not related to genapic though. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, May 24, 2005 at 09:22:47PM +0100, Keir Fraser wrote:> > On 24 May 2005, at 20:58, Puthiyaparambil, Aravindh wrote: > > >I am fine with going down the x86_64 genapic route for Xen. The only > >thing is that I know that IRQ overrides are not present in the x86_64 > >genapic. So that might have to be brought over for the ES7000. > > > >I would like to start working on bringing the x86_64 code over. Will > >this clash with anyone else? > > I''m about halfway through bringing i386 platform code over. I''m working > on smp bootup and cpumask_t right now, but genapic is next and should > be quite simple. I''d rather take the more flexible i386 code in the > first instance (which will immediately support es7000, for example) andIt is actually not more flexible at all for the dynamic case. With a static compile you have some more choices, should you really want to support the Numasaurus (aka NUMAQ) or SGI Visual Workstation (kind of a SGI O2 with a x86 CPU) or Voyager (NUMA 486). Somehow I cannot imagine you really want that though, these are all quite old and obscure machines. A lot of the cruft in the i386 layer even comes from PC98 support (which was a old Japanese not quite PC x86 platform), which was later dropped because it was unmaintained. The hooks it needed were never cleaned up unfortunately. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel