| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
Re: [Xen-ia64-devel] [patch] make Xen assign meta-physical memory in spa
Isaku Yamahata wrote:
> > It seems that you and I are attacking the same issues from
> > the different directions.
> > Your motivation is NUMA and mine is pci-access and driver domain.
> > Could you check/test my patches?
> > (Thanks Akio for pointint it out.)
Hi Isaku,
Yep, at least initially :-) I would get to the PCI issue later, but
first I need to get dom0 to hit userland and thats still quite a bit
away on sn2.
>> >> More work needs to be done in this area, but it is crucial we assign
>> >> memory correctly, in particular for dom0.
> >
> > As the patch comment says interim, so you may already aware of it...
> > complete_dom0_memmap() is for only dom0.
> > libxc/xc_linux_build.c does it for domU.
Nope I wasn't aware of this, thanks. I am still fighting with dom0.
> > I considered about domU case a little.
> > What do you think about the followings?
> > Basically there are two approaches for domU.
> > i.e.
> > - xen vmm itself arranges memory for domU
> > v.s.
> > - user land tools(libxc/xc_linux_build.c) does.
> > It seems that xen/x86 adopted libxc apporach so that the latter
> > would be appropriate for xen/ia64.
I am not quite sure. For the long term I want to see domU having it's
memory assigned in a node-aware fashion too. Otherwise domU will run
completely inefficient on NUMA systems and NUMA information passed on
to userland applications via libnuma will be bogus.
Since some operating systems probably won't be able to handle sparse
memory like that, it would be interesting to have the policy be
something one can set on a per-dom basis.
We should be able to do this quite easily since Xen doesn't overcommit
memory assigned to the doms.
I tried out your patches and they seem to work for me. My patch just
preserved the option for assigning memory as before, but for dom0 we
probably don't even want to provide that feature for the longer term.
With these patches applied I am seeing PAL warnings about unimplemented
PAL call 42 and then a cachable vs uncacheable access in xenmisc.c.
Anyone else seeing this?
Cheers,
Jes
SAL 0.1: Xen/ia64 Xen/ia64 version 0.0
SAL: AP wakeup using external interrupt vector 0xf3
xen_pal_emulator: UNIMPLEMENTED PAL CALL 42!!!!
(XEN) No logical to physical processor mapping available
get_max_cacheline_size: ia64_pal_cache_summary() failed (status=-1)
$$$$$ PANIC in domain 0 (k6=0xf000003015f48000): try to use WB mem attr
on UC page, mpaddr=3ffffffff0068
(XEN) domain_crash_sync called from xenmisc.c:195
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) d 0xf000003015f7c280 domid 0
(XEN) vcpu 0xf000003015f48000 vcpu 0
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home