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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.02.16 at 15:48, <haozhong.zhang@xxxxxxxxx> wrote:
> 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.

Aiui just the leaf names matter for sufficient separation, i.e.
recurring sub-scopes should not be a problem.

> 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.

And how do you imagine to enforce this without parsing the
handed AML? (Remember there's no AML parser in hvmloader.)

Jan

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