RE: [Xen-devel] [Patch 2/2] Add dom0_get_sectioninfo for XEN/VTI

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> However, now I also suspected the necessity a bit. ;-b As you 
> said, that info is produced from outside, and consumed only 
> outside too. There's really no need to bother Xen as a 
> connector. Then cleaner way may be just to pass layout info 
> to device model from domain builder directly.
> If not done that yet, change will be made on qemu then. Do 
> you think so?

I believe this is the right approach.

> >In any event, can't your pursuade your unmodified IA64 
> domains that the 
> >MMIO region lives after the end of RAM? Or is it determined 
> to have it 
> >below 4GB or something?
> >It may be convention to have it below 4GB, but does the code 
> actually 
> >break if its above?
> 
> Ideally the layout is decided by platform, and domain should 
> depend on EFI/ACPI table to make its life. However several 
> issues I think as problem now:
> 
> - Experienced users may feel strange to see a layout not like 
> real hardware, if they don't realize running at VMM.
>
> - Not familiar with qemu... If unmodified domain is 
> configured with 4G memory, and then all MMIO region is moved 
> to >4G area, I'm not sure whether some old 32bit DMA 
> controller within qemu can work properly without re-compile?
> 
> - On unmodified x86 domain with PAE enabled, can 32bit domain 
> handle MMIO >4G if following same policy to move MMIO beyond 
> memory? (If device model has no e820 map). I think the 
> internal type for I/O may be always 32bit... :)

That final point is interesting. Linux is careful thesedays to avoid
ever storing physcial address in 32bits, but its possible earlier
versions were not. 

Anyhow, this is all a discussion for 3.1. I don't want to get distracted
from finishing 3.0 right now, and encourage everyone else to think about
the 3.0 todo list too...

Ian




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