Hi,
On Fri, Apr 20, 2012 at 12:55:24PM +0200, Igor Mammedov wrote:
> >+ /* Memory eject notify method */
> >+ OperationRegion(MEMJ, SystemIO, 0xaf40, 32)
> >+ Field (MEMJ, ByteAcc, NoLock, Preserve)
> >+ {
> >+ MPE, 256
> >+ }
> >+
> >+ Method (MPEJ, 2, NotSerialized) {
> >+ // _EJ0 method - eject callback
> >+ Store(ShiftLeft(1,Arg0), MPE)
> >+ Sleep(200)
> >+ }
> MPE is write only and only one memslot is ejected at a time. Why 256 bit-field is here then?
> Could we use just 1 byte and write a slot number into it and save some io address space this way?
good point. This was implemented similarly to the hot-add/status register only
for symmetry, but you are right, since only one slot is ejected at a time, this
can be reduced to one byte and save space. I will update for the next version.
>
> >+
> >+ /* Memory hotplug notify method */
> >+ OperationRegion(MEST, SystemIO, 0xaf20, 32)
> It's more a suggestion: move it a bit farther to allow maybe 1024 cpus in the future.
> That will prevent compatibility a headache, if we decide to expand support to more then
> 256 cpus.
ok, I will move it to 0xaf80 or higher (so cpu-hotplug could be extended to at
least 1024 cpus)
>
> Or event better to make this address configurable in run-time and build this var along
> with SSDT (converting along the way all other hard-coded io ports to the same generic
> run-time interface). This wish is out of scope of this patch-set, but what
> do you think about the idea?
yes, that would give more flexibility and avoid more compatibility headaches.
As you say it's not a main issue for the series, but I can work on it as we start
converting hardcoded i/o ports to configurable properties.
thanks,
- Vasilis
--
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
