Re: [Xen-devel] Re: [PATCH 2] HVM vcpu add/remove: setup dsdt and madt infrastructure for vcpu add/remove

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 09/12/2009 12:04, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

>> What's the MADT checksum stuff in the DSDT all about? Does the MADT really
>> have to stay consistent and checksummed after boot - I would have assumed
>> that it provides a boot-time snapshot of the system only, and would not be
>> looked at by the OSPM after boot. I haven't looked at the ASL code in detail
>> but I'll surely bet that the approach is fragile.
> 
> Ah, this has to do with the _MAT methods doesn't it. Well, I wonder whether
> the strategy of sharing the _MAT return values and the MADT entries is
> actually sensible. There seems to be no really good reason to do it -- they
> should be consistent at boot-time of course, but after boot the MADT isn't
> expected to remain live and up-to-date I believe? Then each Processor object
> can define its own MAT buffer which it manages entirely by and for itself.

Hmm, well, the ACPI spec's example does have the entries shared I think.
Perhaps it does make sense then, although I'm still unsure whether
maintaining the MADT checksum is required?

In any case the patch will need splitting up some more, and I think there is
still scope for fewer magic numbers between hvmloader and the DSDT. We have
an existing in-memory info structure 'struct bios_info' where you could
stick things like MADT cpu entry base address, MADT checksum address (if
we're really required to keep the csum correct), MADT cpu entry length (if
that can be variable), etc. If we provide more key values like this then we
need fewer, or no, new magic numbers, and potentially you don't need to
reorder our MADT, which will cut down your patch size dramatically.

 -- Keir



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