On Tue, Jun 07, 2016 at 10:48:36AM +0100, Stefano Stabellini wrote: > On Mon, 6 Jun 2016, Julien Grall wrote: > > Hello, > > > > On 06/06/16 13:04, Stefano Stabellini wrote: > > > On Mon, 6 Jun 2016, Julien Grall wrote: > > > > On 06/06/16 12:40, Stefano Stabellini wrote: > > > > > On Tue, 31 May 2016, Shannon Zhao wrote: > > > > > > From: Shannon Zhao <shannon.z...@linaro.org> > > > > > > > > > > ACPI tables for ARM guests should be user configurable: acpi=1 in the > > > > > VM > > > > > config file enables them, with default off. > > > > > > > > The VM system specification for ARM [1] mandates that both ACPI and DT > > > > should > > > > be provided and described the entire VM and its peripheral (see the > > > > section > > > > "Hardware Description"). > > > > > > > > Furthermore, the user may not know if the guest OS will use ACPI or DT > > > > For > > > > instance Redhat is using ACPI whilst Debian is using DT. > > > > > > > > So we have to provide both by default. However, 32-bit domain should > > > > only > > > > have > > > > Device-Tree table created. > > > > > > > > Anyway, the reason should have been described in the commit message. I > > > > would > > > > split this patch in two: introducing prepare ACPI and then GTDT table. > > > > So > > > > we > > > > can provide details in the commit message. > > > > > > All right, let me rephrase then: we should have a VMSPEC=on or off to > > > enable or disable compliance with the VM system specification for ARM. > > > (The good thing about specifications is that there are so many to choose > > > from.) With compliance disabled, we can avoid introducing ACPI tables > > > for the guest. > > > > > > Given that "VMSPEC" is cumbersome, I suggest to introduce a simpler and > > > more meaningful alias: "ACPI" :-) > > > > The VM specification introduces other components such as a SBSA UART > > emulation > > (which is not yet implemented by Xen). > > > > Do we want an option for each components? > > This is a good point. If one wants to avoid ACPI then she probably would > want to avoid SBSA UART emulation too. So maybe after all it might be > better to have a single > > vm_system_spec=1/0 > > option? I am OK with both having multiple options or just one.
If the user is not supposed to pick and choose then using one is fine. We probably don't want to expose such capability anyway. Is the spec going to be updated at some point? Maybe make it some sort of version number? Wei. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
