Hi Dan, I was hoping someone else would bring this up, but alas....
Why do you need to split getreg into get_eflag etc? By definition, wherever you call get_eflag, you have a getreg(R) call with R a constant (and, in this case, R==_IA64_REG_AR_EFLAG). Thus, you can just have a Xen variant of getreg() which checks if R is a constant and, if so, redirects the call to the appropriate code for special registers such as EFLAG. --david On 7/28/05, Magenheimer, Dan (HP Labs Fort Collins) <[EMAIL PROTECTED]> wrote: > Revision 4. Minor formatting change suggested by > Christoph. Also, no change for "symmetry" suggested > by Christoph as Tony wanted to leave as is. > > Tony I think this is now ready to apply. If there is > anything else needed, please let me know. > > Thanks, > Dan Magenheimer > > > -----Original Message----- > > From: Magenheimer, Dan (HP Labs Fort Collins) > > Sent: Thursday, July 14, 2005 3:18 PM > > To: '[email protected]' > > Subject: RE: Xen and the Art of Linux/ia64 Virtualization > > > > Revision 3. Incorporates some more feedback and > > a minor bug fix. > > > > Dan > > > > > -----Original Message----- > > > From: Magenheimer, Dan (HP Labs Fort Collins) > > > Sent: Wednesday, July 06, 2005 2:47 PM > > > To: '[email protected]' > > > Subject: RE: Xen and the Art of Linux/ia64 Virtualization > > > > > > The patch I posted yesterday had a couple of bugs. > > > This version applies cleanly against 2.6.12 and > > > (when augmented with additional files from various > > > Xen subdirectories) has been booted both on Xen/ia64 > > > and on hardware. > > > > > > Note that a patch to drivers/acpi/motherboard.c (that > > > allows for acpi to be enabled on a stubbed acpi tree > > > without a kernel null pointer dereference!) is required > > > and has been submitted separately to the linux-acpi list. > > > > > > With the exception of three short CONFIG_XEN > > > ifdefs, the vast majority of changes in this patch > > > are code rearrangement to enable a number of routines > > > and defines to add one level of abstraction. > > > > > > Comments and feedback would be much appreciated! > > > > > > arch/ia64/Kconfig | 7 + > > > arch/ia64/Makefile | 1 > > > arch/ia64/hp/sim/Makefile | 2 > > > arch/ia64/ia32/elfcore32.h | 2 > > > arch/ia64/ia32/ia32_signal.c | 6 - > > > arch/ia64/ia32/ia32_support.c | 4 - > > > arch/ia64/kernel/entry.S | 30 ++++--- > > > arch/ia64/kernel/head.S | 4 + > > > arch/ia64/kernel/irq_ia64.c | 12 +-- > > > arch/ia64/kernel/pal.S | 5 - > > > arch/ia64/kernel/setup.c | 3 > > > include/asm-ia64/delay.h | 53 ------------- > > > include/asm-ia64/privop.h | 160 > > > ++++++++++++++++++++++++++++++++++++++++++ > > > include/asm-ia64/processor.h | 56 -------------- > > > include/asm-ia64/system.h | 12 +-- > > > 15 files changed, 217 insertions(+), 140 deletions(-) > > > > > > > -----Original Message----- > > > > From: Magenheimer, Dan (HP Labs Fort Collins) > > > > Sent: Tuesday, July 05, 2005 2:21 PM > > > > To: [email protected] > > > > Subject: RE: Xen and the Art of Linux/ia64 Virtualization > > > > > > > > Thanks to excellent feedback from David Mosberger and > > > > Christophe Hellwig, I have greatly cleaned up the attached > > > > patch by using some very nice abstractions. In fact, > > > > most of the bulk in the attached patch results from > > > > moving some code from asm-ia64/{delay,processor}.h to > > > > a new file, asm-ia64/privop.h. And the number of > > > > CONFIG_XEN ifdefs is dramatically reduced. > > > > > > > > More feedback appreciated (including comments about how > > > > close this might be to be ready for submission to Tony). > > > > > > > > Thanks, > > > > Dan Magenheimer > > > > > > > > P.S. Anybody who is attending OLS who wants to talk about > > > > Xen (and specifically Xen/ia64)? I'll be there... send > > > > me email. > > > > > > > > > > > > -- Mosberger Consulting LLC, voice/fax: 510-744-9372, http://www.mosberger-consulting.com/ 35706 Runckel Lane, Fremont, CA 94536 - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
