Hi, Alex and Tristan
Alex, Thank you for your information,
and could you try this patch?
I modified SRAT and lsapic of dom0 for disable cpus.
This patch work fine on our PRIMEQUEST.
>after more thoughts, I think trying NUMA in dom0 is bound to fail or to be
>useless. Memory mapping is virtualized and vcpu can move...
Yeah, I think so, we need properly support NUMA.
Best Regards,
Akio Takebe
>Quoting Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>:
>
>> Hi, Alex, Tristan, Yongkang and all
>>
>> >On Fri, 2007-07-20 at 03:53 +0200, Tristan Gingold wrote:
>> >> On Thu, Jul 19, 2007 at 05:20:26PM -0600, Alex Williamson wrote:
>> >> > On Wed, 2007-07-18 at 16:03 +0900, Akio Takebe wrote:
>> >> > > Hi, all
>> >> > >
>> >> > > This patch fix a issue which dom0 cannot boot with dom0_max_vcpus.
>> >> > > Currently LSAPIC IDs are create by xen,
>> >> > > but ACPI SRAT table is the bare table.
>> >> > > So on some boxes node_cpuid[].phys_id are different from
>> >> > > cpu_physical_id()s,
>> >> > > and we cannot boot dom0.
>> >> > > I think xen should pass the bare LSAPIC ID to dom0.
>> >> Hi Akio,
>> >>
>> >> I am not sure this patch is complete. Some code of Xen assumes vcpu_id
>> >> ==
>> >> id (get_lid, IPI).
>> >> I think you'd better to patch the SRAT (if it is possible).
>> >
>> > That may be the way to go, it should be possible. BTW, now that I
>> >look at it again, lsapic->id == 0 really looks like an implementation
>> >dependent check. Thanks,
>> I'm sorry, and I'll debug more.
>> I'll check vcpu_id and SRAT code.
>> Tristan's idea may be good, I'll try it.
>Hi,
>
>after more thoughts, I think trying NUMA in dom0 is bound to fail or to be
>useless. Memory mapping is virtualized and vcpu can move...
>
>Tristan.
debug_numa_test.patch
Description: Binary data
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home