|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/2] hvmloader: Allow the toolstack to choose WAET optimisations
On Fri, 2013-11-29 at 10:57 +0000, Andrew Cooper wrote:
> On 29/11/13 09:55, Ian Campbell wrote:
> > On Tue, 2013-11-26 at 20:39 +0000, Andrew Cooper wrote:
> >> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> >> CC: Keir Fraser <keir@xxxxxxx>
> >> CC: Jan Beulich <JBeulich@xxxxxxxx>
> >> CC: Tim Deegan <tim@xxxxxxx>
> >> CC: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> >> CC: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
> >> ---
> >> tools/firmware/hvmloader/acpi/acpi2_0.h | 4 ++++
> >> tools/firmware/hvmloader/acpi/build.c | 32
> >> +++++++++++++++++++++++++
> >> tools/firmware/hvmloader/acpi/static_tables.c | 12 +---------
> >> 3 files changed, 37 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h
> >> b/tools/firmware/hvmloader/acpi/acpi2_0.h
> >> index 7b22d80..bebe4e6 100644
> >> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h
> >> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
> >> @@ -303,6 +303,10 @@ struct acpi_20_waet {
> >> struct acpi_header header;
> >> uint32_t flags;
> >> };
> >> +#define ACPI_WAET_RTC_NO_ACK (1<<0) /* RTC requires no int
> >> acknowledge */
> >> +#define ACPI_WAET_TIMER_ONE_READ (1<<1) /* PM timer requires only one
> >> read */
> >> +
> >> +#define ACPI_WAET_DEFAULT_FLAGS (ACPI_WAET_TIMER_ONE_READ)
> >>
> >> /*
> >> * Multiple APIC Flags.
> >> diff --git a/tools/firmware/hvmloader/acpi/build.c
> >> b/tools/firmware/hvmloader/acpi/build.c
> >> index f1dd3f0..b9e209a 100644
> >> --- a/tools/firmware/hvmloader/acpi/build.c
> >> +++ b/tools/firmware/hvmloader/acpi/build.c
> >> @@ -23,6 +23,8 @@
> >> #include "ssdt_pm.h"
> >> #include "../config.h"
> >> #include "../util.h"
> >> +#include "../hypercall.h"
> >> +#include <xen/hvm/params.h>
> >> #include <xen/hvm/hvm_xs_strings.h>
> >>
> >> #define ACPI_MAX_SECONDARY_TABLES 16
> >> @@ -189,6 +191,9 @@ static struct acpi_20_hpet *construct_hpet(void)
> >> static struct acpi_20_waet *construct_waet(void)
> >> {
> >> struct acpi_20_waet *waet;
> >> + const char *s;
> >> + struct xen_hvm_param p =
> >> + { .domid = DOMID_SELF, .index = HVM_PARAM_RTC_MODE };
> >>
> >> waet = mem_alloc(sizeof(*waet), 16);
> >> if (!waet) return NULL;
> >> @@ -196,8 +201,35 @@ static struct acpi_20_waet *construct_waet(void)
> >> memcpy(waet, &Waet, sizeof(*waet));
> >>
> >> waet->header.length = sizeof(*waet);
> >> +
> >> + s = xenstore_read("platform/waet-rtc-noack", NULL);
> >> + if ( s )
> >> + {
> >> + if ( !strncmp(s, "1", 1) || !strncmp(s, "true", 4) )
> > Oh, and we generally seem to only care in hvmloader about "1" and "0"
> > rather than true/false wibble/woggle etc. Since this is an internal
> > protocol I think we don't need to be terribly accepting.
> >
> > You need to update docs/misc/xenstore-paths.markdown.
> >
> > Ian.
> >
>
> Xapi works with "true/false" in these values.
It sounds like xapi needs fixing then.
> In the past, all platform
> flags were not dealt with by hvmloader directly - they were all integers
> in HVMPARAMS or the start-info table.
>
> From a "debugging issues with reference to xenstore" point of view, it
> is substantially easier to have booleans as true/false, to visually
> differentiate them from genuine integer 0/1's
Regardless, the xenstore convention is 0 and 1, mixing styles is worse
than either option.
Ian.
> In my copious free time, I was going to formally introduce
> "xenstore_read_bool()" in hvmloader.
>
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |