On Wed, Oct 05, 2011 at 08:35:26AM -0200, Michael S. Tsirkin wrote:
> On Tue, Oct 04, 2011 at 10:52:33PM -0400, Kevin O'Connor wrote:
> > Something like:
> >
> > ACPI_EXTRACT ssdt_proc_obj
> > Processor (CPAA, 0xAA, 0x0000b010, 0x06) {
> >
>
> I considered this, sure. We could parse AML to figure out
> what is the object type we are trying to look up.
>
> However I decided sanity-checking that we get the right type of object
> in AML is better. This way if iasl output format breaks
> we will have a better chance to detect that.
> Makes sense?
Yes. I guess one could do ACPI_EXTRACT_PROCESSOR for the sanity
check.
> Also this can not be as generic as it seems: each type of
> object in AML bytecode is encoded slightly differently.
> So we would still have types of objects we support
> and types of object we don't.
Yes.
> > which would produce something like:
> >
> > static struct aml_object ssdt_proc_obj = {.addr=0x24, .size=0x40, .param=0x28};
>
> What is the param offset here?
The location of the first byte of the parameters (the same as you had
for ssdt_proc_name). Normally, AML objects take the form: <id>
<length> <fixed params> <variable param list>. The <length> is itself
of variable length, so passing in the start of the fixed parameters
would make manipulating the results easier.
> > As for the other parts of this patch series - I'm still leary of
> > changing the DSDT dynamically.
>
> Hmm, not sure I understand why. Could you explain pls?
Sure:
- The DSDT is big and has several cross-functional users. Patching up
the DSDT for hotplug when the DSDT also has unrelated stuff (eg,
mouse) seems ugly.
- The PCI hotplug stuff is generating a whole bunch of devices and the
dynamic code is effectively disabling the unwanted ones. It seems
nicer to dynamically generate the desired entries instead of bulk
generating and dynamically blanking.
- The CPU hotplug has similar requirements, but is implemented
differently - it generates the CPU objects dynamically. It's not
desirable to bulk generate the CPU objects and "blank" them
dynamically, because 255 CPU objects would noticeably increase
SeaBIOS' static size.
- Some time back there were patches floating around to pass the DSDT
into SeaBIOS via fw_cfg interface. Those patches never made it in
(I forget why), but the basic functionality seemed sound. Patching
the DSDT in SeaBIOS would seem to eliminate that possibility.
None of these would be road-blocks. However, they make me want to
consider other approaches.
> > and then just memcpy the "hotplug_obj" N number of times into the ssdt
> > for each available slot. (This would be on top of the DSDT
> > simplification patch series that I posted previously.)
>
> This assumes all devices are the same. But unfortunately this will not
> work for other devices such as VGA.
The VGA device can't be hotplugged, so I don't see why that would be
an issue.
-Kevin
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
