[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-ia64-devel] consoles, iosapics, and device interrupts
On Fri, 2005-11-18 at 08:14 -0800, Magenheimer, Dan (HP Labs Fort Collins) wrote: > Sounds like good progress, but a couple comments: > > I don't think we should put the ACPI namespace code into Xen/ia64. > IIRC, this is a *lot* of code and I don't think it is worth > adding it just so we can have console input to Xen > without going through Dom0. I think the Cambridge Xen > team would agree... I agree, I don't want to add it either. Unfortunately ACPI is the only way for DIG compliant boxes to describe much of the system. It's definitely a balance point for para-virtualization vs full virtualization. Ideally we could tweak ACPI namespace so that ACPI objects are listed as not present for guests that aren't privileged to use them. This could include not only ACPI described UARTs, but PCI root bridges, processors, thermal devices, buttons, etc... This all gets pretty ugly, but I'm not convinced we aren't going to have to go down that path at some point. I'll search through the main archives to see if anyone has a plan for this. > Is it possible to have console input routed to Xen > through Dom0 via the virtual console? This of course > will be worthless before Xen boots Dom0, or if Dom0 crashes. > But there really is limited value for direct console input > into Xen except for debugging -- and it is a potentially > big security hole. I think that's what we're trying to do. Remove hpsim and the Linux serial console leaving only the xen virtual console. I suppose the other option would be to eliminate the xen console and let dom0 talk to the hardware directly. This might be as simple as the hpsim fix that I submitted, but then we lose access to getting to the debugging prompt. The security risk of the debugging console doesn't seem so big to me. Don't you have to have physical access to the console device (VGA or serial)? Adding a password to access the xen console would probably be pragmatic, but I don't think we need to go overboard when access is already so limited. > Last, it might be worth promoting this discussion to > xen-devel as there might be some useful input from > Cambridge and the IBM Power port team. Alex, could > you summarize the discussion to date and post it to > xen-devel for comment? I think we're currently just trying to get up to parity w/ x86. x86 has a different architecture for interrupts, so doesn't really have the same IOSAPIC issue. AFAICT though, interrupts are virualized on x86. I need to get a better feel for the code to see what they've done around ACPI though. Power likely doesn't care about ACPI at all. Thanks, Alex -- Alex Williamson HP Linux & Open Source Lab _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |