On Mon, Jan 07, 2008 at 03:49:54PM +0000, de Dinechin, Christophe (Integrity
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.
> 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
> 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.
Xen-ia64-devel mailing list