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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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