WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: ´ð¸´: [Xen-ia64-devel] Re: [PATCH 0/12] various fixes related the xe

On Mon, Jan 07, 2008 at 03:49:54PM +0000, de Dinechin, Christophe (Integrity 
VM) wrote:
> Hello,


Interesting note from an insider!

> Another issue that Tristan did not point out is that HPUX uses large-format 
> VHPT (virtually hashed page table). This means that for each entry in the 
> page table, there is more data than the Linux page table can hold, in 
> particular protection keys that are not related to RIDs, etc. Correct me if 
> I'm wrong, but a quick look at xen/arch/ia64/xen/ivt.S indicates that this is 
> basically Linux's own ivt.S, meaning short-format VHPT, meaning that Xen 
> simply cannot store sufficient data today to emulate the HPUX more complex 
> memory model correctly. IMO that's a big ouch point. I suspect this will also 
> wreck VMS's memory protection: even if it appears to work, VMS memory domains 
> may not be isolated as they should.

No you're wrong here :-)  Xen use a long-format VHPT and minimally support
long format domain.  I think the support is complete enough for VMS although
we don't yet support protection keys.  Does HP-UX use them ?

> If you want good enough performance, you should try fairly recent versions of 
> HPUX. For example, older versions will not invoke PAL_HALT_LIGHT when idle, 
> and so this makes idle detection difficult.

Ok!

> I agree with Tristan about device and platform emulation. However, HPUX 
> already runs in a VM (HP Integrity Virtual Machines) that emulates a platform 
> with minimal chipset. This has helped us get rid of several faulty internal 
> assumptions, and HPUX is now a little better at looking at actual hardware 
> instead of assuming what it should look like.

Good to know.

> Device drivers are another problem, because HPUX does not support many common 
> PC peripherals, and Xen may be emulating one of these by default. I don't 
> have time right now to look at the Xen source code (older Xen source code on 
> the web seems obsolete in that respect compared to what I heard recently on 
> this list), but if someone could reply with a quick description of what Xen 
> can emulate nowadays, it would be easier to evaluate the chances that HPUX 
> will be happy with it.

Can you tell use more about the HPUX requirements ?  VMS seems able to deal
with CMD649 and a serial port.  Can HPUX boot with only these two devices ?
Our disk controller and VGA adapter are really basic.

> I also agree with Tristan regarding endianness. Please note that HPUX is not 
> stricly big-endian, firmware must be run little endian on Itanium. So the 
> monitor must be ready for endianness changes within an HPUX domain.

This is definitely not a difficult problem, but may prevent HP-UX from going
far.

> Once this runs, there will be a number of interesting issues with 
> performance. For instance, HPUX uses the task priority register (TPR) a lot, 
> notably in spinlock routines. It switches to physical mode (PSR.dt=0) in 
> low-level TLB handlers, meaning that a fast emulationf of physical mode 
> load/stores is useful. There are several other things, but now is probably 
> too early to even think about them ;-)

Performance optimization...  A very long topic!

> I don't mean to discourage you. On the contrary, I know it can be done 
> because we've done it with HPVM, and I'd be happy to help as much as I'm 
> allowed to.

I plan to work on HPUX right after VMS.

Tristan.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel

<Prev in Thread] Current Thread [Next in Thread>