[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.