| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [Patch 2/2] Add dom0_get_sectioninfo for XEN/VTI
> 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
|
|
|
| |
|
Home