[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Wed, 09 Dec 2009 12:04:56 +0000
  • Cc:
  • Delivery-date: Wed, 09 Dec 2009 04:05:24 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acp4skvEix7hn2Q2TfebXz2pqbXZQAAD1LspAAGM+IM=
  • Thread-topic: [Xen-devel] Re: [PATCH 2] HVM vcpu add/remove: setup dsdt and madt infrastructure for vcpu add/remove

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

> What's PROC_BASE, and what's APIC_MADT_PTR? No comments attached to them:
> they look like random magic numbers.
> 
> DSDT code generation can be done in mk_dsdt.c, rather then addign
> preprocessor stuff to the static part of the DSDT in dsdt.asl. So move stuff
> there instead.
> 
> 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.

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.