Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Haozhong Zhang <haozhong.zhang@xxxxxxxxx>]

On 02/24/16 09:54, Jan Beulich wrote:
> >>> On 24.02.16 at 16:48, <haozhong.zhang@xxxxxxxxx> wrote:
> > On 02/24/16 07:24, Jan Beulich wrote:
> >> >>> On 24.02.16 at 14:28, <haozhong.zhang@xxxxxxxxx> wrote:
> >> > On 02/18/16 10:17, Jan Beulich wrote:
> >> >> >>> On 01.02.16 at 06:44, <haozhong.zhang@xxxxxxxxx> wrote:
> >> >> > 3.3 Guest ACPI Emulation
> >> >> > 
> >> >> > 3.3.1 My Design
> >> >> > 
> >> >> >  Guest ACPI emulation is composed of two parts: building guest NFIT
> >> >> >  and SSDT that defines ACPI namespace devices for NVDIMM, and
> >> >> >  emulating guest _DSM.
> >> >> > 
> >> >> >  (1) Building Guest ACPI Tables
> >> >> > 
> >> >> >   This design reuses and extends hvmloader's existing mechanism that
> >> >> >   loads passthrough ACPI tables from binary files to load NFIT and
> >> >> >   SSDT tables built by QEMU:
> >> >> >   1) Because the current QEMU does not building any ACPI tables when
> >> >> >      it runs as the Xen device model, this design needs to patch QEMU
> >> >> >      to build NFIT and SSDT (so far only NFIT and SSDT) in this case.
> >> >> > 
> >> >> >   2) QEMU copies NFIT and SSDT to the end of guest memory below
> >> >> >      4G. The guest address and size of those tables are written into
> >> >> >      xenstore 
> >> >> > (/local/domain/domid/hvmloader/dm-acpi/{address,length}).
> >> >> > 
> >> >> >   3) hvmloader is patched to probe and load device model passthrough
> >> >> >      ACPI tables from above xenstore keys. The detected ACPI tables
> >> >> >      are then appended to the end of existing guest ACPI tables just
> >> >> >      like what current construct_passthrough_tables() does.
> >> >> > 
> >> >> >   Reasons for this design are listed below:
> >> >> >   - NFIT and SSDT in question are quite self-contained, i.e. they do
> >> >> >     not refer to other ACPI tables and not conflict with existing
> >> >> >     guest ACPI tables in Xen. Therefore, it is safe to copy them from
> >> >> >     QEMU and append to existing guest ACPI tables.
> >> >> 
> >> >> How is this not conflicting being guaranteed? In particular I don't
> >> >> see how tables containing AML code and coming from different
> >> >> sources won't possibly cause ACPI name space collisions.
> >> >>
> >> > 
> >> > Really there is no effective mechanism to avoid ACPI name space
> >> > collisions (and other kinds of conflicts) between ACPI tables loaded
> >> > from QEMU and ACPI tables built by hvmloader. Because which ACPI tables
> >> > are loaded is determined by developers, IMO it's developers'
> >> > responsibility to avoid any collisions and conflicts with existing ACPI
> >> > tables.
> >> 
> >> Right, but this needs to be spelled out and settled on at design
> >> time (i.e. now), rather leaving things unspecified, awaiting the
> >> first clash.
> > 
> > So that means if no collision-proof mechanism is introduced, Xen should not
> > trust any passed-in ACPI tables and should build them by itself?
> 
> Basically yes, albeit collision-proof may be too much to demand.
> Simply separating name spaces (for hvmloader and qemu to have
> their own sub-spaces) would be sufficient imo. We should trust
> ourselves to play by such a specification.
>

I don't quite understand 'separating name spaces'. Do you mean, for
example, if both hvmloader and qemu want to put a namespace device under
\_SB, they could be put in different sub-scopes under \_SB? But it does
not work for Linux at least.

Anyway, we may avoid some conflicts between ACPI tables/objects by
restricting which tables and objects can be passed from QEMU to Xen:
(1) For ACPI tables, xen does not accept those built by itself,
    e.g. DSDT and SSDT.
(2) xen does not accept ACPI tables for devices that are not attached to
    a domain, e.g. if NFIT cannot be passed if a domain does not have
    vNVDIMM.
(3) For ACPI objects, xen only accepts namespace devices and requires
    their names does not conflict with existing ones provided by Xen.

In implementation, QEMU could put the passed-in ACPI tables and objects in
a series of blobs in following format:
  +------+------+--....--+
  | type | size |  data  |
  +------+------+--....--+
where
(1) 'type' indicates which data are stored in this blob:
        0 for ACPI table,
        1 for ACPI namespace device,
(2) 'size' indicates this blob's size in bytes. The next blob (if exist)
    can be found by add 'size' to the base address of the current blob.
(3) 'data' is of variant-length and stores the actual passed content:
    (a) for type 0 blob (ACPI table), a complete ACPI table including the
        table header is stored in 'data'
    (b) for type 1 blob (ACPI namespace device), at the beginning of
       'data' is a 4 bytes device name, and followed is AML code within
       that device, e.g. for a device
          Device (DEV0) {
              Name (_HID, "ACPI1234")
              Method (_DSM) { ... }
          }
       "DEV0" is stored at the beginning of 'data', and then is AML code of
          Name (_HID, "ACPI1234")
          Method (_DSM) { ... }
     
The number and the starting guest address of all blobs are passed to Xen
via xenstore. Xen toolstack/hvmloader can enumerate those blobs and
check signatures or name in 'data' according to their types.

The acceptable ACPI tables will be appended to existing tables built by
Xen. For acceptable ACPI namespace devices, hvmloader will recreate AML
devices for them, and put those AML devices in a new SSDT. Only a small
piece of code to build just AML device entry rather than a comprehensive
AML builder is needed then.

Haozhong

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel