Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug

[li guang]

在 2013-01-10四的 19:57 +0100，Vasilis Liaskovitis写道：
> > > 
> > > IIRC q35 supports memory hotplug natively (picked up in some
> > > discussion).  Is that correct?
> > > 
> > From previous discussion I also understand that q35 supports native 
> > hotplug. 
> > Sections 5.1 and 5.2 of the spec describe the MCH registers but the native
> > memory hotplug specifics are not yet clear to me. Any pointers from the
> > spec are welcome.
> 
> Ping. Could anyone who's familiar with the q35 spec provide some pointers on
> native memory hotplug details in the spec? I see pcie hotplug registers but 
> can't
> find memory hotplug interface details. If I am not mistaken, the spec is here:
> http://www.intel.com/design/chipsets/datashts/316966.htm
> 
> Is the q35 memory hotplug support supposed to be an shpc-like interface geared
> towards memory slots instead of pci slots?
> 

seems there's no so-called q35-native support


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug

[li guang]

在 2013-02-28四的 11:18 +0100，Vasilis Liaskovitis写道：
> Hi,
> 
> sorry for the delay.
> On Tue, Feb 19, 2013 at 07:39:40PM -0300, Erlon Cruz wrote:
> > On Tue, Dec 18, 2012 at 10:41 AM, Vasilis Liaskovitis <
> > vasilis.liaskovi...@profitbricks.com> wrote:
> > 
> > > This is v4 of the ACPI memory hotplug functionality. Only x86_64 target is
> > > supported (both i440fx and q35). There are still several issues, but it's
> > > been a while since v3 and I wanted to get some more feedback on the 
> > > current
> > > state of the patchseries.
> > >
> > >
> > We are working in memory hotplug functionality on pSeries machine. I'm
> > wondering whether and how we can better integrate things. Do you think the
> > DIMM abstraction is generic enough to be used in other machine types?
> 
> I think the DimmDevice is generic enough but I am open to other suggestions. 
> 
> A related issue is that the patchseries uses a DimmBus to hot-add and 
> hot-remove
> DimmDevice. Another approach that has been suggested is to use links<> between
> DimmDevices and the dram controller device (piix4 or mch for pc and q35-pc
> machines respectively). This would be more similar to the CPUState/qom
> patches - see Andreas Färber's earlier reply to this thread.
> 
> I think we should get some consensus from the community/maintainers before we
> continue to integrate. 
> 
> I haven't updated the series for a while, but I can rework if there is a more
> clear direction for the community.
> 
> Another open issue is reference counting of memoryregions in qemu memory
> model. In order to make memory hot-remove operations safe, we need to remove
> a memoryregion after all users (e.g. both guest and block layer) have stopped
> using it,

it seems it mostly up to the user who want to hot-(un)plug,
if user want to un-plug a memory which is kernel's main memory, kernel
will always run on it(never stop) unless power off.
and if guest stops, all DIMMs should be safe to hot-remove,
or else we should do something to let user can unlock all reference.

>  see discussion at
> http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg03986.html. There was 
> a
> relevant ibm patchset
> https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02697.html
> but it was not merged.
> 
> > 
> > 
> > > Overview:
> > >
> > > Dimm device layout is modeled with a normal qemu device:
> > >
> > > "-device dimm,id=name,size=sz,node=pxm,populated=on|off,bus=membus.0"
> > >
> > >
> >  How does this will handle the no-hotplugable memory for example the memory
> > passed in '-m' parameter?
> 
> The non-hotpluggable initial memory (-m) is currently not modelled at all as a
> DimmDevice. We may want to model it though.
> 
> thanks,
> - Vasilis
> 



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 01/30] Add ACPI_EXTRACT_DEVICE* macros

[li guang]

seems these changes is in seebios now.

在 2012-12-18二的 13:41 +0100，Vasilis Liaskovitis写道：
> This allows to extract the beginning, end and name of a Device object.
> ---
>  tools/acpi_extract.py |   28 
>  1 files changed, 28 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/acpi_extract.py b/tools/acpi_extract.py
> index 3295678..3191f53 100755
> --- a/tools/acpi_extract.py
> +++ b/tools/acpi_extract.py
> @@ -217,6 +217,28 @@ def aml_package_start(offset):
>  offset += 1
>  return offset + aml_pkglen_bytes(offset) + 1
>  
> +def aml_device_start(offset):
> +#0x5B 0x82 DeviceOp PkgLength NameString ProcID
> +if ((aml[offset] != 0x5B) or (aml[offset + 1] != 0x82)):
> +die( "Name offset 0x%x: expected 0x5B 0x83 actual 0x%x 0x%x" %
> + (offset, aml[offset], aml[offset + 1]));
> +return offset
> +
> +def aml_device_string(offset):
> +#0x5B 0x82 DeviceOp PkgLength NameString ProcID
> +start = aml_device_start(offset)
> +offset += 2
> +pkglenbytes = aml_pkglen_bytes(offset)
> +offset += pkglenbytes
> +return offset
> +
> +def aml_device_end(offset):
> +start = aml_device_start(offset)
> +offset += 2
> +pkglenbytes = aml_pkglen_bytes(offset)
> +pkglen = aml_pkglen(offset)
> +return offset + pkglen
> +
>  lineno = 0
>  for line in fileinput.input():
>  # Strip trailing newline
> @@ -307,6 +329,12 @@ for i in range(len(asl)):
>  offset = aml_processor_end(offset)
>  elif (directive == "ACPI_EXTRACT_PKG_START"):
>  offset = aml_package_start(offset)
> +elif (directive == "ACPI_EXTRACT_DEVICE_START"):
> +offset = aml_device_start(offset)
> +elif (directive == "ACPI_EXTRACT_DEVICE_STRING"):
> +offset = aml_device_string(offset)
> +elif (directive == "ACPI_EXTRACT_DEVICE_END"):
> +offset = aml_device_end(offset)
>  else:
>  die("Unsupported directive %s" % directive)
>  



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 07/30] Add SIZE type to qdev properties

[li guang]

在 2012-12-18二的 13:41 +0100，Vasilis Liaskovitis写道：
> This patch adds a 'SIZE' type property to qdev.
> 
> It will make dimm description more convenient by allowing sizes to be 
> specified
> with K,M,G,T prefixes instead of number of bytes e.g.:
> -device dimm,id=mem0,size=2G,bus=membus.0
> 
> Credits go to Ian Molton for original patch. See:
> http://patchwork.ozlabs.org/patch/38835/
> 
> Signed-off-by: Vasilis Liaskovitis 
> ---
>  hw/qdev-properties.c |   60 
> ++
>  hw/qdev-properties.h |3 ++
>  qemu-option.c|2 +-
>  qemu-option.h|2 +
>  4 files changed, 66 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> index 81d901c..a77f760 100644
> --- a/hw/qdev-properties.c
> +++ b/hw/qdev-properties.c
> @@ -1279,3 +1279,63 @@ void qemu_add_globals(void)
>  {
>  qemu_opts_foreach(qemu_find_opts("global"), qdev_add_one_global, NULL, 
> 0);
>  }
> +
> +/* --- 64bit unsigned int 'size' type --- */
> +
> +static void get_size(Object *obj, Visitor *v, void *opaque,
> +   const char *name, Error **errp)
> +{
> +DeviceState *dev = DEVICE(obj);
> +Property *prop = opaque;
> +uint64_t *ptr = qdev_get_prop_ptr(dev, prop);
> +
> +visit_type_size(v, ptr, name, errp);
> +}
> +
> +static void set_size(Object *obj, Visitor *v, void *opaque,
> +   const char *name, Error **errp)
> +{
> +DeviceState *dev = DEVICE(obj);
> +Property *prop = opaque;
> +uint64_t *ptr = qdev_get_prop_ptr(dev, prop);
> +
> +if (dev->state != DEV_STATE_CREATED) {
> +error_set(errp, QERR_PERMISSION_DENIED);
> +return;
> +}
> +
> +visit_type_size(v, ptr, name, errp);
> +}
> +
> +static int parse_size(DeviceState *dev, Property *prop, const char *str)
> +{
> +uint64_t *ptr = qdev_get_prop_ptr(dev, prop);
> +Error *errp = NULL;
> +
> +if (str != NULL) {
> +parse_option_size(prop->name, str, ptr, &errp);
> +}
> +assert_no_error(errp);
> +return 0;
> +}
> +
> +static int print_size(DeviceState *dev, Property *prop, char *dest, size_t 
> len)
> +{
> +uint64_t *ptr = qdev_get_prop_ptr(dev, prop);
> +char suffixes[] = {'T', 'G', 'M', 'K', 'B'};
> +int i = 0;
> +uint64_t div;
> +
> +for (div = (long int)1 << 40; !(*ptr / div) ; div >>= 10) {
> +i++;
> +}
> +return snprintf(dest, len, "%0.03f%c", (double)*ptr/div, suffixes[i]);
^^ ^^^  
> +}
> +

IMHO, you may need (double)(*ptr/div), for type cast is right
associated.

> +PropertyInfo qdev_prop_size = {
> +.name  = "size",
> +.parse = parse_size,
> +.print = print_size,
> +.get = get_size,
> +.set = set_size,
> +};
> diff --git a/hw/qdev-properties.h b/hw/qdev-properties.h
> index 5b046ab..0182bef 100644
> --- a/hw/qdev-properties.h
> +++ b/hw/qdev-properties.h
> @@ -14,6 +14,7 @@ extern PropertyInfo qdev_prop_uint64;
>  extern PropertyInfo qdev_prop_hex8;
>  extern PropertyInfo qdev_prop_hex32;
>  extern PropertyInfo qdev_prop_hex64;
> +extern PropertyInfo qdev_prop_size;
>  extern PropertyInfo qdev_prop_string;
>  extern PropertyInfo qdev_prop_chr;
>  extern PropertyInfo qdev_prop_ptr;
> @@ -67,6 +68,8 @@ extern PropertyInfo qdev_prop_pci_host_devaddr;
>  DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_hex32, uint32_t)
>  #define DEFINE_PROP_HEX64(_n, _s, _f, _d)   \
>  DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_hex64, uint64_t)
> +#define DEFINE_PROP_SIZE(_n, _s, _f, _d)   \
> +DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_size, uint64_t)
>  #define DEFINE_PROP_PCI_DEVFN(_n, _s, _f, _d)   \
>  DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_pci_devfn, int32_t)
>  
> diff --git a/qemu-option.c b/qemu-option.c
> index 27891e7..38e0a11 100644
> --- a/qemu-option.c
> +++ b/qemu-option.c
> @@ -203,7 +203,7 @@ static void parse_option_number(const char *name, const 
> char *value,
>  }
>  }
>  
> -static void parse_option_size(const char *name, const char *value,
> +void parse_option_size(const char *name, const char *value,
>uint64_t *ret, Error **errp)
>  {
>  char *postfix;
> diff --git a/qemu-option.h b/qemu-option.h
> index ca72986..b8ee5b3 100644
> --- a/qemu-option.h
> +++ b/qemu-option.h
> @@ -152,5 +152,7 @@ typedef int (*qemu_opts_loopfunc)(QemuOpts *opts, void 
> *opaque);
>  int qemu_opts_print(QemuOpts *opts, void *dummy);
>  int qemu_opts_foreach(QemuOptsList *list, qemu_opts_loopfunc func, void 
> *opaque,
>int abort_on_failure);
> +void parse_option_size(const char *name, const char *value,
> +  uint64_t *ret, Error **errp);
>  
>  #endif



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug

[li guang]

在 2013-01-09三的 01:08 +0100，Andreas Färber写道：
> Am 18.12.2012 13:41, schrieb Vasilis Liaskovitis:
> > Because dimm layout needs to be configured on machine-boot, all dimm devices
> > need to be specified on startup command line (either with populated=on or 
> > with
> > populated=off). The dimm information is stored in dimm configuration 
> > structures.
> > 
> > After machine startup, dimms are hot-added or removed with normal device_add
> > and device_del operations e.g.:
> > Hot-add syntax: "device_add dimm,id=mydimm0,bus=membus.0"
> > Hot-remove syntax: "device_del dimm,id=mydimm0"
> 
> This sounds contradictory: Either all devices need to be specified on
> the command line, or they can be hot-added via monitor.
> 
> Assuming a fixed layout at startup, I wonder if there is another clever
> way to model this... For CPU hotplug Anthony had suggested to have a
> fixed set of link properties that get set to a CPU socket as
> needed. Might a similar strategy work for memory, i.e. a
> startup-configured amount of links on /machine/dimm[n] that point
> to a QOM DIMM object or NULL if unpopulated? Hot(un)plug would then
> simply work via QMP qom-set command. (CC'ing some people)


Sorry, what's link<>, did it adopted by cpu-QOM?
can you give some hints?

Thanks!




___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 07/30] Add SIZE type to qdev properties

[li guang]

在 2013-03-20三的 08:24 -0600，Eric Blake写道：
> On 03/20/2013 12:06 AM, li guang wrote:
> 
> >> +return snprintf(dest, len, "%0.03f%c", (double)*ptr/div, suffixes[i]);
> > ^^ ^^^  
> >> +}
> >> +
> > 
> > IMHO, you may need (double)(*ptr/div), for type cast is right
> > associated.
> 
> No, the code as written is correct, and your proposal would be wrong.
> As written, it is evaluated as:
> 
> ((double)*ptr) / div
> 
> which promotes the division to floating point.  Your proposal would do
> the division (*ptr/div) as an integral (truncating) division, and only
> then cast the result to double.
> 

Yes, you're right,
amazing c type cast!



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 09/30] Implement dimm device abstraction

[li guang]

在 2012-12-18二的 13:41 +0100，Vasilis Liaskovitis写道：
> Each hotplug-able memory slot is a DimmDevice. All DimmDevices are attached
> to a new bus called DimmBus. This bus is introduced so that we no longer
> depend on hotplug-capability of main system bus (the main bus does not allow
> hotplugging). The DimmBus should be attached to a chipset Device (i440fx in 
> case
> of the pc)
> 
> A hot-add operation for a particular dimm:
> - creates a new DimmDevice and attaches it to the DimmBus
> - creates a new MemoryRegion of the given physical address offset, size and
> node proximity, and attaches it to main system memory as a sub_region.
> 
> Hotplug operations are done through normal device_add commands.
> Also add properties to DimmDevice.
> 
> v3->v4: Removed hot-remove functions. Will be offered in separate patches.
> 
> Signed-off-by: Vasilis Liaskovitis 
> ---
>  hw/Makefile.objs |2 +-
>  hw/dimm.c|  245 
> ++
>  hw/dimm.h|   89 
>  3 files changed, 335 insertions(+), 1 deletions(-)
>  create mode 100644 hw/dimm.c
>  create mode 100644 hw/dimm.h
> 
> diff --git a/hw/Makefile.objs b/hw/Makefile.objs
> index d581d8d..51494c9 100644
> --- a/hw/Makefile.objs
> +++ b/hw/Makefile.objs
> @@ -29,7 +29,7 @@ common-obj-$(CONFIG_I8254) += i8254_common.o i8254.o
>  common-obj-$(CONFIG_PCSPK) += pcspk.o
>  common-obj-$(CONFIG_PCKBD) += pckbd.o
>  common-obj-$(CONFIG_FDC) += fdc.o
> -common-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o acpi_ich9.o smbus_ich9.o
> +common-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o acpi_ich9.o smbus_ich9.o 
> dimm.o
>  common-obj-$(CONFIG_APM) += pm_smbus.o apm.o
>  common-obj-$(CONFIG_DMA) += dma.o
>  common-obj-$(CONFIG_I82374) += i82374.o
> diff --git a/hw/dimm.c b/hw/dimm.c
> new file mode 100644
> index 000..e384952
> --- /dev/null
> +++ b/hw/dimm.c
> @@ -0,0 +1,245 @@
> +/*
> + * Dimm device for Memory Hotplug
> + *
> + * Copyright ProfitBricks GmbH 2012
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, see 
> 
> + */
> +
> +#include "trace.h"
> +#include "qdev.h"
> +#include "dimm.h"
> +#include 
> +#include "../exec-memory.h"
> +#include "qmp-commands.h"
> +
> +/* the following list is used to hold dimm config info before machine
> + * is initialized. After machine init, the list is not used anymore.*/
> +static DimmConfiglist dimmconfig_list =
> +   QTAILQ_HEAD_INITIALIZER(dimmconfig_list);
> +
> +/* the list of memory buses */
> +static QLIST_HEAD(, DimmBus) memory_buses;
> +
> +static void dimmbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
> +static char *dimmbus_get_fw_dev_path(DeviceState *dev);
> +
> +static Property dimm_properties[] = {
> +DEFINE_PROP_UINT64("start", DimmDevice, start, 0),
> +DEFINE_PROP_SIZE("size", DimmDevice, size, DEFAULT_DIMMSIZE),
> +DEFINE_PROP_UINT32("node", DimmDevice, node, 0),
> +DEFINE_PROP_BIT("populated", DimmDevice, populated, 0, false),
> +DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void dimmbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
> +{
> +}
> +
> +static char *dimmbus_get_fw_dev_path(DeviceState *dev)
> +{
> +char path[40];
> +
> +snprintf(path, sizeof(path), "%s", qdev_fw_name(dev));
> +return strdup(path);
> +}
> +
> +static void dimm_bus_class_init(ObjectClass *klass, void *data)
> +{
> +BusClass *k = BUS_CLASS(klass);
> +
> +k->print_dev = dimmbus_dev_print;
> +k->get_fw_dev_path = dimmbus_get_fw_dev_path;
> +}
> +
> +static void dimm_bus_initfn(Object *obj)
> +{
> +DimmBus *bus = DIMM_BUS(obj);
> +QTAILQ_INIT(&bus->dimmconfig_list);
> +QTAILQ_INIT(&bus->dimmlist);
> +}
> +
> +static const TypeInfo dimm_bus_info = {
> +.name = TYPE_DIMM_BUS,
> +.parent = TYPE_BUS,
> +.instance_size = sizeof(DimmBus),
> +.instance_init = dimm_bus_initfn,
> +.class_init = dimm_bus_class_init,
> +};
> +
> +DimmBus *dimm_bus_create(Object *parent, const char *name, uint32_t 
> max_dimms,
> +dimm_calcoffset_fn pmc_set_offset)
> +{
> +DimmBus *memory_bus;
> +DimmConfig *dimm_cfg, *next_cfg;
> +uint32_t num_dimms = 0;
> +
> +memory_bus = g_malloc0(dimm_bus_info.instance_size);
> +memory_bus->qbus.name = name ? g_strdup(name) : "membus.0";
> +qbus_create_inplace(&memory_bus->qbus, TYPE_DIMM_BUS, DEVIC

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug

[li guang]

在 2013-03-26二的 17:58 +0100，Vasilis Liaskovitis写道：
> Hi,
> 
> On Tue, Mar 19, 2013 at 02:30:25PM +0800, li guang wrote:
> > 在 2013-01-10四的 19:57 +0100，Vasilis Liaskovitis写道：
> > > > > 
> > > > > IIRC q35 supports memory hotplug natively (picked up in some
> > > > > discussion).  Is that correct?
> > > > > 
> > > > From previous discussion I also understand that q35 supports native 
> > > > hotplug. 
> > > > Sections 5.1 and 5.2 of the spec describe the MCH registers but the 
> > > > native
> > > > memory hotplug specifics are not yet clear to me. Any pointers from the
> > > > spec are welcome.
> > > 
> > > Ping. Could anyone who's familiar with the q35 spec provide some pointers 
> > > on
> > > native memory hotplug details in the spec? I see pcie hotplug registers 
> > > but can't
> > > find memory hotplug interface details. If I am not mistaken, the spec is 
> > > here:
> > > http://www.intel.com/design/chipsets/datashts/316966.htm
> > > 
> > > Is the q35 memory hotplug support supposed to be an shpc-like interface 
> > > geared
> > > towards memory slots instead of pci slots?
> > > 
> > 
> > seems there's no so-called q35-native support
> 
> that was also my first impression when scanning the specification. Wasn't 
> native
> memory hotplug capabilities one of the reasons that q35 got picked as the next
> pc chipset?

Um, I can't find the original statement of q35,
but I think if we can't find in intel's official
SPEC, then we have to say 'there's no q35-native support'.



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug

[li guang]

在 2013-03-26二的 17:43 +0100，Vasilis Liaskovitis写道：
> Hi,
> 
> On Tue, Mar 19, 2013 at 03:28:38PM +0800, li guang wrote:
> [...]
> > > > > This is v4 of the ACPI memory hotplug functionality. Only x86_64 
> > > > > target is
> > > > > supported (both i440fx and q35). There are still several issues, but 
> > > > > it's
> > > > > been a while since v3 and I wanted to get some more feedback on the 
> > > > > current
> > > > > state of the patchseries.
> > > > >
> > > > >
> > > > We are working in memory hotplug functionality on pSeries machine. I'm
> > > > wondering whether and how we can better integrate things. Do you think 
> > > > the
> > > > DIMM abstraction is generic enough to be used in other machine types?
> > > 
> > > I think the DimmDevice is generic enough but I am open to other 
> > > suggestions. 
> > > 
> > > A related issue is that the patchseries uses a DimmBus to hot-add and 
> > > hot-remove
> > > DimmDevice. Another approach that has been suggested is to use links<> 
> > > between
> > > DimmDevices and the dram controller device (piix4 or mch for pc and q35-pc
> > > machines respectively). This would be more similar to the CPUState/qom
> > > patches - see Andreas Färber's earlier reply to this thread.
> > > 
> > > I think we should get some consensus from the community/maintainers 
> > > before we
> > > continue to integrate. 
> > > 
> > > I haven't updated the series for a while, but I can rework if there is a 
> > > more
> > > clear direction for the community.
> > > 
> > > Another open issue is reference counting of memoryregions in qemu memory
> > > model. In order to make memory hot-remove operations safe, we need to 
> > > remove
> > > a memoryregion after all users (e.g. both guest and block layer) have 
> > > stopped
> > > using it,
> > 
> > it seems it mostly up to the user who want to hot-(un)plug,
> > if user want to un-plug a memory which is kernel's main memory, kernel
> > will always run on it(never stop) unless power off.
> > and if guest stops, all DIMMs should be safe to hot-remove,
> > or else we should do something to let user can unlock all reference.
> 
> it's not only the guest-side that needs to stop using it, we need to make sure
> that the qemu block layer is also not using the memory region anymore. See 
> the 2
> links below for discussion:
> 

can't we simply track this(MemoryRegion) usage by ref-count?
e.g.
every time mr used, inc ref-count, then dec it when unused
even for cpu_physical_memory_map and other potential users.

> > >  see discussion at
> > > http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg03986.html. There 
> > > was a
> > > relevant ibm patchset
> > > https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02697.html
> > > but it was not merged.
> > > 
> thanks,
> 
> - Vasilis



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug

[li guang]

在 2013-03-26二的 11:20 -0300，Eduardo Habkost写道：
> On Wed, Mar 20, 2013 at 02:18:00PM +0800, li guang wrote:
> > 在 2013-01-09三的 01:08 +0100，Andreas Färber写道：
> > > Am 18.12.2012 13:41, schrieb Vasilis Liaskovitis:
> > > > Because dimm layout needs to be configured on machine-boot, all dimm 
> > > > devices
> > > > need to be specified on startup command line (either with populated=on 
> > > > or with
> > > > populated=off). The dimm information is stored in dimm configuration 
> > > > structures.
> > > > 
> > > > After machine startup, dimms are hot-added or removed with normal 
> > > > device_add
> > > > and device_del operations e.g.:
> > > > Hot-add syntax: "device_add dimm,id=mydimm0,bus=membus.0"
> > > > Hot-remove syntax: "device_del dimm,id=mydimm0"
> > > 
> > > This sounds contradictory: Either all devices need to be specified on
> > > the command line, or they can be hot-added via monitor.
> > > 
> > > Assuming a fixed layout at startup, I wonder if there is another clever
> > > way to model this... For CPU hotplug Anthony had suggested to have a
> > > fixed set of link properties that get set to a CPU socket as
> > > needed. Might a similar strategy work for memory, i.e. a
> > > startup-configured amount of links on /machine/dimm[n] that point
> > > to a QOM DIMM object or NULL if unpopulated? Hot(un)plug would then
> > > simply work via QMP qom-set command. (CC'ing some people)
> > 
> > 
> > Sorry, what's link<>, did it adopted by cpu-QOM?
> 
> "link<...>" is a QOM construct, allowing properties that point to other
> objects. We don't use it on the CPU objects yet.
> 
> > can you give some hints?
> 
> Look for mentions of "link" in the doc comments at include/qom/object.h.
> 

OK, I see, Thanks!


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [RFC][PATCH 0/2] Embedded Controller chip emulation

[li guang]

Embedded Controller chip could commonly be found
at platforms for laptop, it generally does
power management, keyboard and mouse simulation,
ACPI defined operation, low-speed devices handling ...
It talks with OS via io-port 0x60/0x54, 0x62/0x66,
the first pair is for i8042 compatible, the last
pair is for ACPI functions.
As QEMU has done power management, i8042 emulation,
this RFC patch will only focus on ACPI functions.
you can find standard description a ACPI SPEC
"ACPI Embedded Controller Interface Specification"


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [RFC][PATCH 2/2] hw: add Embedded Controller chip emulation

[li guang]

在 2013-04-17三的 19:54 +0200，Andreas Färber写道：
> Am 17.04.2013 09:23, schrieb liguang:
> > this work implemented Embedded Controller chip emulation
> > which was defined at ACPI SEPC v5 chapter 12:
> > "ACPI Embedded Controller Interface Specification"
> > 
> > commonly Embedded Controller will emulate keyboard,
> > mouse, handle ACPI defined operations and some
> > low-speed devices like SMbus.
> > 
> > Signed-off-by: liguang 
> > ---
> >  hw/ec.c |  113 
> > +++
> 
> hw/misc/ec.c? hw/i386/ec.c? Not directly in hw/ anymore.
> 
> >  hw/ec.h |   20 +++
> >  2 files changed, 133 insertions(+), 0 deletions(-)
> >  create mode 100644 hw/ec.c
> >  create mode 100644 hw/ec.h
> > 
> > diff --git a/hw/ec.c b/hw/ec.c
> > new file mode 100644
> > index 000..69c92cf
> > --- /dev/null
> > +++ b/hw/ec.c
> > @@ -0,0 +1,113 @@
> > +#include "ec.h"
> > +#include "hw/hw.h"
> > +#include "hw/isa/isa.h"
> > +#include "sysemu/sysemu.h"
> > +
> > +#define TYPE_EC_DEV
> 
> Missing string value.
> 
> > +#define EC_DEV(obj) \
> > +OBJECT_CHECK(ECState, (obj), TYPE_EC_DEV)
> > +
> > +static char ec_acpi_space[EC_ACPI_SPACE_SIZE] = {0};
> > +
> > +typedef struct ECState {
> > +ISADevice dev;
> 
> parent_obj and white line please.
> 
> > +char cmd;
> > +char status;
> > +char data;
> > +char irq;
> > +char buf;
> 
> char seems a bit unsafe here, since it might be signed or unsigned.
> Suggest uint8_t.
> 
> > +MemoryRegion io;
> > +} ECState;
> > +
> > +
> > +static void io62_write(void *opaque, hwaddr addr, uint64_t val, unsigned 
> > size)
> > +{
> > +ECState *s = opaque;
> > +char tmp = val & 0xff;
> > +
> > +if (s->status & EC_ACPI_CMD) {
> > +s->buf = tmp;
> > +s->status &= ~EC_ACPI_CMD;
> > +} else {
> > +if (tmp < EC_ACPI_SPACE_SIZE) {
> > +ec_acpi_space[s->buf] = tmp;
> > +}
> > +}
> > +}
> > +
> > +static uint64_t io62_read(void *opaque, hwaddr addr, unsigned size)
> > +{
> > +return s->data;
> > +}
> > +
> > +static void io66_write(void *opaque, hwaddr addr, uint64_t val, unsigned 
> > size)
> > +{
> > +ECState *s = opaque;
> > +
> > +s->status = EC_ACPI_CMD | EC_ACPI_IBF;
> > +
> > +switch (val & 0xff) {
> > +case EC_ACPI_CMD_READ:
> > +case EC_ACPI_CMD_WRITE:
> > +case EC_ACPI_CMD_BURST_EN:
> > +s->statu |= EC_ACPI_BST;
> 
> s->status
> 
> > +case EC_ACPI_CMD_BURST_DN:
> > +s->statu &= ~EC_ACPI_BST;
> 
> s->status
> 
> > +case EC_ACPI_CMD_QUERY:
> > +s->cmd = val & 0xff;
> > +case default:
> > +break;
> > +}
> > +}
> > +
> > +static uint64_t io66_read(void *opaque, hwaddr addr, unsigned size)
> > +{
> > +ECState *s = opaque;
> > +
> > +return s->status;
> > +}
> > +
> > +static const MemoryRegionOps io62_io_ops = {
> > +.write = io62_write,
> > +.read = io62_read,
> > +.endianness = DEVICE_NATIVE_ENDIAN,
> > +.impl = {
> > +.min_access_size = 1,
> > +.max_access_size = 1,
> > +},
> > +};
> > +
> > +static const MemoryRegionOps io66_io_ops = {
> > +.write = io66_write,
> > +.read = io66_read,
> > +.endianness = DEVICE_NATIVE_ENDIAN,
> > +.impl = {
> > +.min_access_size = 1,
> > +.max_access_size = 1,
> > +},
> > +};
> > +
> > +static void ec_realizefn(DeviceState *dev, Error **err)
> > +{
> > +ISADevice *isadev = ISA_DEVICE(dev);
> > +ECState *s = EC_DEV(dev);
> > +
> > +isa_init_irq(isadev, &s->irq, 0xb);
> > +
> 
> > +memory_region_init_io(&s->io, &io62_io_ops, NULL, "ec-acpi-data", 1);
> > +isa_register_ioport(isadev, &s->io, 0x62);
> > +
> > +memory_region_init_io(&s->io, &io66_io_ops, NULL, "ec-acpi-cmd", 1);
> > +isa_register_ioport(isadev, &s->io, 0x66);
> 
> Since you are not defining any properties, all of this could go into a
> .instance_init function.
> 
> But I am glad to see a realize function being used. :)
> 
> > +
> > +s->status = 0;
> > +s->data = 0;
> 
> This is probably not necessary here, since all fields get
> zero-initialized. It should rather go into a reset function.
> 
> > +}
> > +
> > +static void ec_class_initfn(ObjectClass *klass, void *data)
> > +{
> > +DeviceClass *dc = DEVICE_CLASS(klass);
> > +
> > +dc->realize = ec_realizefn;
> > +dc->no_user = 1;
> > +}
> 
> This file ends with an unused static function, it's missing type
> registration.

OK, will fix all,

Thanks you so much!

> 
> I figure this device should rather be a specific (real) model, reflected
> in a particular name, similar to how we have different watchdog devices
> rather than a "watchdog" device.

does it has to be specific model?
my reason to be generic like "generic-sdhci"(SD host controller) device
is mostly all EC devices play a similar role, and we do not have to
know the difference between EC chip from different vendors

> 
> > diff --git a/hw/ec.h b/hw/ec

Re: [SeaBIOS] [RFC][PATCH 0/2] Embedded Controller chip emulation

[li guang]

Oh, No,
that's a private interface for Intel's AMT,
this is a chip embedded in mainboard.

在 2013-04-17三的 11:04 +0200，Fred .写道：
> HECI ?
> http://en.wikipedia.org/wiki/Host_Embedded_Controller_Interface
> 
> 
> 
> On Wed, Apr 17, 2013 at 9:32 AM, li guang 
> wrote:
> Embedded Controller chip could commonly be found
> at platforms for laptop, it generally does
> power management, keyboard and mouse simulation,
> ACPI defined operation, low-speed devices handling ...
> It talks with OS via io-port 0x60/0x54, 0x62/0x66,
> the first pair is for i8042 compatible, the last
> pair is for ACPI functions.
> As QEMU has done power management, i8042 emulation,
> this RFC patch will only focus on ACPI functions.
> you can find standard description a ACPI SPEC
> "ACPI Embedded Controller Interface Specification"
> 
> 
> ___
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
> 
> 



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC][PATCH 2/2] hw: add Embedded Controller chip emulation

[li guang]

No, sorry.
As this is RFC patch,
I sent it only for demo my thought.

在 2013-04-17三的 12:41 +0200，Mark Marshall写道：
> Hi.
> 
> 
> At least one major bug (noted below), have you tested all of this yet?
> 
> 
> MM
> 
> 
> On 17 April 2013 09:23, liguang  wrote:
> this work implemented Embedded Controller chip emulation
> which was defined at ACPI SEPC v5 chapter 12:
> "ACPI Embedded Controller Interface Specification"
> 
> commonly Embedded Controller will emulate keyboard,
> mouse, handle ACPI defined operations and some
> low-speed devices like SMbus.
> 
> Signed-off-by: liguang 
> ---
>  hw/ec.c |  113
> +++
>  hw/ec.h |   20 +++
>  2 files changed, 133 insertions(+), 0 deletions(-)
>  create mode 100644 hw/ec.c
>  create mode 100644 hw/ec.h
> 
> diff --git a/hw/ec.c b/hw/ec.c
> new file mode 100644
> index 000..69c92cf
> --- /dev/null
> +++ b/hw/ec.c
> @@ -0,0 +1,113 @@
> +#include "ec.h"
> +#include "hw/hw.h"
> +#include "hw/isa/isa.h"
> +#include "sysemu/sysemu.h"
> +
> +#define TYPE_EC_DEV
> +#define EC_DEV(obj) \
> +OBJECT_CHECK(ECState, (obj), TYPE_EC_DEV)
> +
> +static char ec_acpi_space[EC_ACPI_SPACE_SIZE] = {0};
> +
> +typedef struct ECState {
> +ISADevice dev;
> +char cmd;
> +char status;
> +char data;
> +char irq;
> +char buf;
> +MemoryRegion io;
> +} ECState;
> +
> +
> +static void io62_write(void *opaque, hwaddr addr, uint64_t
> val, unsigned size)
> +{
> +ECState *s = opaque;
> +char tmp = val & 0xff;
> +
> +if (s->status & EC_ACPI_CMD) {
> +s->buf = tmp;
> +s->status &= ~EC_ACPI_CMD;
> +} else {
> +if (tmp < EC_ACPI_SPACE_SIZE) {
> +ec_acpi_space[s->buf] = tmp;
> +}
> +}
> +}
> +
> +static uint64_t io62_read(void *opaque, hwaddr addr, unsigned
> size)
> +{
> +return s->data;
> +}
> +
> +static void io66_write(void *opaque, hwaddr addr, uint64_t
> val, unsigned size)
> +{
> +ECState *s = opaque;
> +
> +s->status = EC_ACPI_CMD | EC_ACPI_IBF;
> +
> +switch (val & 0xff) {
> +case EC_ACPI_CMD_READ:
> +case EC_ACPI_CMD_WRITE:
> +case EC_ACPI_CMD_BURST_EN:
> +s->statu |= EC_ACPI_BST;
> +case EC_ACPI_CMD_BURST_DN:
> +s->statu &= ~EC_ACPI_BST;
> +case EC_ACPI_CMD_QUERY:
> +s->cmd = val & 0xff;
> +case default:
> +break;
> +}
> +}
> 
> You've missed 'break' here a few times.
>  
> 
> +
> +static uint64_t io66_read(void *opaque, hwaddr addr, unsigned
> size)
> +{
> +ECState *s = opaque;
> +
> +return s->status;
> +}
> +
> +static const MemoryRegionOps io62_io_ops = {
> +.write = io62_write,
> +.read = io62_read,
> +.endianness = DEVICE_NATIVE_ENDIAN,
> +.impl = {
> +.min_access_size = 1,
> +.max_access_size = 1,
> +},
> +};
> +
> +static const MemoryRegionOps io66_io_ops = {
> +.write = io66_write,
> +.read = io66_read,
> +.endianness = DEVICE_NATIVE_ENDIAN,
> +.impl = {
> +.min_access_size = 1,
> +.max_access_size = 1,
> +},
> +};
> +
> +static void ec_realizefn(DeviceState *dev, Error **err)
> +{
> +ISADevice *isadev = ISA_DEVICE(dev);
> +ECState *s = EC_DEV(dev);
> +
> +isa_init_irq(isadev, &s->irq, 0xb);
> +
> +memory_region_init_io(&s->io, &io62_io_ops, NULL,
> "ec-acpi-data", 1);
> +isa_register_ioport(isadev, &s->io, 0x62);
> +
> +memory_region_init_io(&s->io, &io66_io_ops, NULL,
> "ec-acpi-cmd", 1);
> +isa_register_ioport(isadev, &s->io, 0x66);
> +
> +s->status = 0;
> +s->data = 0;
> +}
> +
> +static void ec_class_initfn(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +
> +dc->realize = ec_realizefn;
> +dc->no_user = 1;
> +}
> diff --git a/hw/ec.h b/hw/ec.h
> new file 

Re: [SeaBIOS] [RFC][PATCH 1/2] acpi: add ASL for Embedded Controller

[li guang]

在 2013-04-17三的 07:46 -0600，Marc Jones写道：
> What EC is this for? The device and interface is defined by the spec,
> but the offsets and methods are custom for every EC.
> 
> 

you're mostly right,
the specific content ACPI space will vary 
for different boards, this one just for
a common case

> 
> 
> Marc
> 
> 
> On Wed, Apr 17, 2013 at 1:22 AM, liguang 
> wrote:
> defined at ACPI SPEC v5 chapter 12:
> "ACPI Embedded Controller Interface Specification"
> 
> Signed-off-by: liguang 
> ---
>  src/acpi-dsdt-ec.dsl |  106
> ++
>  1 files changed, 106 insertions(+), 0 deletions(-)
>  create mode 100644 src/acpi-dsdt-ec.dsl
> 
> diff --git a/src/acpi-dsdt-ec.dsl b/src/acpi-dsdt-ec.dsl
> new file mode 100644
> index 000..6bd8edd
> --- /dev/null
> +++ b/src/acpi-dsdt-ec.dsl
> @@ -0,0 +1,106 @@
> +/*
> + * This program is free software; you can redistribute it
> and/or modify
> + * it under the terms of the GNU General Public License as
> published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be
> useful,
> + * but WITHOUT ANY WARRANTY; without even the implied
> warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
> the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> License
> + * along with this program; if not, write to the Free
> Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +
> +Device (EC0)
> +{
> +   Name (_HID, EISAID ("PNP0C09"))
> +   Name(_UID, 1)
> +
> +   Method(_CRS, 0)
> +   {
> +   Name(BFFR, ResourceTemplate()
> +   {
> +   IO(Decode16, 0x62, 0x62, 0, 1)  // ACPI
> DATA IN/OUT
> +   IO(Decode16, 0x66, 0x66, 0, 1)  // CMD/STS
> +   IRQ(Edge, ActiveHigh, Exclusive) {0x0B}
> +   })
> +Return(BFFR)
> +   }
> +
> +   OperationRegion(ECF0, EmbeddedControl, 0, 0xFF)
> +Field(ECF2, ByteAcc, Lock, Preserve)
> +   {
> +   Offset(1),
> +   STMP,   8,  // 1,  Sensor Temperature
> +   ACPW,   8,  // 2,  AC Power (AC
> Present = 1, else 0)
> +   LIDS,   8,  // 3,  Lid State (Lid Open
> = 1, else 0)
> +   PBNS,   8,  // 4,  Power Button State
> (Pressed = 1, else 0)
> +   BTST,   8,  // 5,  Battery Status
> +   BTCR,   8,  // 6,  Battery Current
> Rate
> +   BTCC,   8,  // 7,  Battery Current
> Capacity
> +   BTVT,   8,  // 8,  Battery Voltage
> +   offset(0x10),
> +   SPTR,   8,  // 5,  SMBus Protocol
> Register
> +   SSTS,   8,  // 5,  SMBus Status
> Register
> +   SADR,   8,  // 6,  SMBus Address
> Register
> +   SCMD,   8,  // 7,  SMBus Command
> Register
> +   SBFR,   256,// 8,  SMBus Block Buffer
> +   SCNT,   8,  // 40, SMBus Block Count
> +   }
> +
> +   Method(_REG, 2)
> +   {
> +   }
> +
> +   /* AC status: present */
> +   Method(_Q01, 0, NotSerialized)
> +   {
> +   Notify (AC, 0x80)
> +   }
> +
> +   /* AC status: dispear*/
> +   Method(_Q02, 0, NotSerialized)
> +   {
> +   Notify (AC, 0x80)
> +   }
> +
> +Method(_Q04, 0, NotSerialized)
> +{
> +   Notify(LID, 0x80)
> +}
> +
> +Method(_Q04, 0, NotSerialized)
> +{
> +   Notify(LID, 0x80)
> +}
> +
> +   Device(AC)
> +   {
> +   Name(_HID, "ACPI0003")
> +   Name(_UID, 0x00)
> +   Name(_PCL, Package() { \_SB } )
> +
> +   Method(_PSR, 0, NotSerialized)
> +   {
> +   return (ACPW)
> +   }
> +
> +  

Re: [SeaBIOS] [Qemu-devel] [PATCH 4/4][seabios] ec: add ASL for ACPI Embedded Controller

[li guang]

Add seabios mail-list

在 2013-05-22三的 11:46 +0800，liguang写道：
> Signed-off-by: liguang 
> ---
>  src/acpi-dsdt.dsl |1 +
>  src/ec.dsl|   51 
> +
>  src/q35-acpi-dsdt.dsl |1 +
>  3 files changed, 53 insertions(+), 0 deletions(-)
>  create mode 100644 src/ec.dsl
> 
> diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
> index 158f6b4..4fa2b9a 100644
> --- a/src/acpi-dsdt.dsl
> +++ b/src/acpi-dsdt.dsl
> @@ -112,6 +112,7 @@ DefinitionBlock (
>  }
>  Name(FDEN, 1)
>  }
> +#include "ec.dsl"
>  }
>  
>  #include "acpi-dsdt-isa.dsl"
> diff --git a/src/ec.dsl b/src/ec.dsl
> new file mode 100644
> index 000..c8be420
> --- /dev/null
> +++ b/src/ec.dsl
> @@ -0,0 +1,51 @@
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> + */
> +
> +Device (EC0)
> +{
> + Name(_HID, EISAID ("PNP0C09"))
> + Name(_UID, 1)
> +
> + Method(_CRS, 0)
> + {
> + Name(BFFR, ResourceTemplate()
> + {
> + IO(Decode16, 0x62, 0x62, 0, 1)  // ACPI DATA 
> IN/OUT
> + IO(Decode16, 0x66, 0x66, 0, 1)  // CMD/STS
> + })
> + Return(BFFR)
> + }
> +
> + OperationRegion(ECFD, EmbeddedControl, 0, 0xFF)
> + Field(ECFD, ByteAcc, Lock, Preserve)
> + {   Offset(1),
> + CPUS,   8,  // 1, CPU status
> + CPUN,   8,  // 2, CPU index
> + }
> +
> + Name(_GPE, 17)
> +
> + Method(_Q01)
> + {
> + If(LEqual(1, CPUS))
> + {
> + Store(0, CPUS)
> + }
> + Else
> + {
> + Store(1, CPUS)
> + }
> + }
> +}
> diff --git a/src/q35-acpi-dsdt.dsl b/src/q35-acpi-dsdt.dsl
> index c031d83..056b4f8 100644
> --- a/src/q35-acpi-dsdt.dsl
> +++ b/src/q35-acpi-dsdt.dsl
> @@ -167,6 +167,7 @@ DefinitionBlock (
>  FDEN,   1
>  }
>  }
> +#include "ec.dsl"
>  }
>  
>  #include "acpi-dsdt-isa.dsl"



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] KVM call agenda for 2013-05-28

[li guang]

在 2013-05-23四的 15:41 +0300，Michael S. Tsirkin写道：
> Juan is not available now, and Anthony asked for
> agenda to be sent early.
> So here comes:
> 
> Agenda for the meeting Tue, May 28:
> 
> - Generating acpi tables
> 
> - Switching the call to a bi-weekly schedule
> 
> Please, send any topic that you are interested in covering.

"add ACPI Embedded Controller"

it can work as an event carrier, so ACPI events 
can be passed between platform(like QEMU emulated)
and OS, OS can execute _Qxx method which defined
by yourself.
this mechanism can be very flexible, and you can
avoid bothering to create some special devices
for QEMU and drivers for linux kernel.
I don't have many examples,
e.g. CPU hotplug,
we can pass hotplug event by _Qxx method, and,
Embedded Controller driver of linux kernel can
get this event, so, it can trigger cpu_up process,
and you'll don't need 
"echo 1 > /sys/devices/system/cpu/cpu1/online"

may you think of it,

Thanks!



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] EC space vs SystemIO for cpu hotplug

[li guang]

Hi, Igor and all

based on the patches "pass cpu online/offline event bewteen QEMU",
http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg04135.html

I'd like to go further, IMHO, too many specific operation regions of
SystemIO have been created for specific usage, like pci-hotplug,
cpu-hotplug, pvpanic, debugcon, and so on, are not so good thing,
in real world, obviously none of them, and more worse, they themselves
and operations are scattered in several code snippets.

but via EC's ACPI space, the *created* SystemIOs can be totally removed,
and we got a centrally controlled and rational and flexible approach for
OS and platform communication, because EC is standard and it really
exists in real world(hardware platform).

may you think of it, if we can use EC space instead of specific SystemIO
for cpu hotplug case, I append a simple patch for seabios.


diff --git a/src/acpi-dsdt-cpu-hotplug.dsl
b/src/acpi-dsdt-cpu-hotplug.dsl
index 0f3e83b..869373b 100644
--- a/src/acpi-dsdt-cpu-hotplug.dsl
+++ b/src/acpi-dsdt-cpu-hotplug.dsl
@@ -6,6 +6,7 @@ Scope(\_SB) {
 /* Objects filled in by run-time generated SSDT */
 External(NTFY, MethodObj)
 External(CPON, PkgObj)
+External(PRS, BuffObj)
 
 /* Methods called by run-time generated SSDT Processor objects */
 Method(CPMA, 1, NotSerialized) {
@@ -38,10 +39,10 @@ Scope(\_SB) {
 }
 
 /* CPU hotplug notify method */
-OperationRegion(PRST, SystemIO, 0xaf00, 32)
-Field(PRST, ByteAcc, NoLock, Preserve) {
-PRS, 256
-}
+//   OperationRegion(PRST, SystemIO, 0xaf00, 32)
+//Field(PRST, ByteAcc, NoLock, Preserve) {
+//  PRS, 256
+//  }
 Method(PRSC, 0) {
 // Local5 = active cpu bitmap
 Store(PRS, Local5)
diff --git a/src/acpi-dsdt-isa.dsl b/src/acpi-dsdt-isa.dsl
index 2b9c3a0..4567edb 100644
--- a/src/acpi-dsdt-isa.dsl
+++ b/src/acpi-dsdt-isa.dsl
@@ -117,6 +117,7 @@ Scope(\_SB.PCI0.ISA) {
Offset(1),
CPUS,   8,  // 1, CPU plug/unplug status map
CPUN,   8,  // 2, CPU index
+   PRS,256,// 3. CPU status map
}
 
Name(_GPE, 3)



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [PATCH 5/6] load_linux: report open kernel file & its size error

[li guang]

OK, will fix.
Thanks!

在 2013-02-04一的 18:20 +，Blue Swirl写道：
> On Mon, Feb 4, 2013 at 2:27 AM, liguang  wrote:
> > Signed-off-by: liguang 
> > ---
> >  hw/pc.c |   14 +++---
> >  1 files changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/pc.c b/hw/pc.c
> > index 01d00f6..0ccd775 100644
> > --- a/hw/pc.c
> > +++ b/hw/pc.c
> > @@ -652,12 +652,20 @@ static void load_linux(void *fw_cfg,
> >  char *vmode;
> >
> >  /* Align to 16 bytes as a paranoia measure */
> > -cmdline_size = (strlen(kernel_cmdline)+16) & ~15;
> > +cmdline_size = (strlen(kernel_cmdline)+16) & ~0xf;
> 
> Here 15 is 16 - 1, so 0xf seems out of place. I'd use QEMU_ALIGN_UP().
> 
> If you touch the line, please add spaces around '+'.
> 
> >
> >  /* load the kernel header */
> >  f = fopen(kernel_filename, "rb");
> > -if (!f || !(kernel_size = get_file_size(f)) ||
> > -fread(header, 1, MIN(ARRAY_SIZE(header), kernel_size), f) !=
> > +if (!f) {
> > +fprintf(stderr, "can't open kernel image file\n");
> 
> The error message from strerror(errno) would be interesting.
> 
> > +exit(1);
> > +}
> > +kernel_size = get_file_size(f);
> > +if (kernel_size <= 0) {
> > +fprintf(stderr, "can't get size of kernel image file\n");
> > +exit(1);
> > +}
> > +if (fread(header, 1, MIN(ARRAY_SIZE(header), kernel_size), f) !=
> >  MIN(ARRAY_SIZE(header), kernel_size)) {
> >  fprintf(stderr, "qemu: could not load kernel '%s': %s\n",
> >  kernel_filename, strerror(errno));
> > --
> > 1.7.2.5
> >
> >



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [seabios][PATCH 1/2] move all acpi-table related definitions to acpi.h

[li guang]

在 2013-02-06三的 23:15 -0500，Kevin O'Connor写道：
> On Mon, Feb 04, 2013 at 10:27:59AM +0800, liguang wrote:
> > Signed-off-by: liguang 
> 
> Thanks.  Some comments.
> 
> [...]
> > --- a/src/acpi.h
> > +++ b/src/acpi.h
> [...]
> > +#include "acpi-dsdt.hex"
> 
> Moving the acpi structure defines to the header is fine, but moving
> the DSDT code into the header is definitely not right.

OK, will remove this include.

> 
> -Kevin
> 



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [seabios][PATCH 2/2] acpi: change numa data format from fw_cfg interface

[li guang]

Sorry for late reply

在 2013-02-06三的 23:18 -0500，Kevin O'Connor写道：
> On Mon, Feb 04, 2013 at 10:28:00AM +0800, liguang wrote:
> > the old numa format got form fw_cfg is:
> > number of nodes
> > node id of cpu (array)
> > node memory size (array)
> > 
> > now, format it like array of:
> > apci_map,
> > memory_size,
> > 
> > it has the advantage of simple and clear.
> 
> With this change, will old versions of seabios work with new versions
> of qemu, and old versions of qemu work with new versions of seabios?

may be not.

> 
> Also, can you provide a high-level summary of why this change is
> useful to an end-user?

This change have nothing to do with end-user,
just for clear design.

> 
> -Kevin
> 



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Seabios PATCH] make reboot-timeout to static for using it after POST phase

[li guang]

在 2013-03-05二的 10:06 +0800，Amos Kong写道：
> From: Kevin O'Connor 
> 
> Memory allocated with malloc_tmp() can't be used after the POST
> phase. The reboot-timeout inside romfile could not be loaded in
> boot_fail(). The patch saved reboot-timeout to a static variable,
> it fixed the regression bug introduced by commit 59d6ca52
> 
> I already tested this patch, reboot-timeout parameter of qemu
> works now.
> @ qemu -boot reboot-timeout=1000 ...
> 
> Signed-off-by: Kevin O'Connor 
> Signed-off-by: Amos Kong 
> ---
>  src/boot.c |   13 -
>  1 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/src/boot.c b/src/boot.c
> index ec411b7..325fac0 100644
> --- a/src/boot.c
> +++ b/src/boot.c
> @@ -235,6 +235,7 @@ int bootprio_find_usb(struct usbdevice_s *usbdev, int lun)
>   * Boot setup
>   /
>  
> +static int BootRetryTime;
>  static int CheckFloppySig = 1;
>  
>  #define DEFAULT_PRIO   
> @@ -271,6 +272,8 @@ boot_init(void)
>  }
>  }
>  
> +BootRetryTime = romfile_loadint("etc/boot-fail-wait", 60*1000);
> +
>  loadBootOrder();
>  }
>  
> @@ -629,15 +632,15 @@ boot_rom(u32 vector)
>  static void
>  boot_fail(void)
>  {
> -u32 retrytime = romfile_loadint("etc/boot-fail-wait", 60*1000);
> -if (retrytime == (u32)-1)
> +if (BootRetryTime == (u32)-1)
>  printf("No bootable device.\n");
>  else
> -printf("No bootable device.  Retrying in %d seconds.\n", 
> retrytime/1000);
> +printf("No bootable device.  Retrying in %d seconds.\n"
> +   , BootRetryTime/1000);
>  // Wait for 'retrytime' milliseconds and then reboot.

s/retrytime/BootRetryTime

> -u32 end = calc_future_timer(retrytime);
> +u32 end = calc_future_timer(BootRetryTime);
>  for (;;) {
> -if (retrytime != (u32)-1 && check_timer(end))
> +if (BootRetryTime != (u32)-1 && check_timer(end))
>  break;
>  yield_toirq();
>  }



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios