This series allows the toolstack to choose (by way of XenStore platform flags) whether the domain is expecting to make use of RTC mode noack performance optimisations. It also switches the implict default back to rtc_mode_strict, which is the safe default for Xen to have. This fixes a longstanding regression in Win2k3SP2 only where its access pattern causes it to fall into an infinite loop reading RTC RegC. Questions for thought: * Does it make sense to allow customisation of ACPI_WAET_TIMER_ONE_READ ? There is no sitation where an admin should turn it off. * I believe this is safe wrt migrations, but am not certain enough to say for sure. This is a critical point, as the bad default (and regression) has been in Xen since late in the Xen-4.3 development cycle. -- 1.7.10.4
Andrew Cooper
2013-Nov-26 20:39 UTC
[PATCH 1/2] x86/vRTC: Make rtc_mode_{strict, no_ack} a per-domain option
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> CC: Keir Fraser <keir@xen.org> CC: Jan Beulich <JBeulich@suse.com> CC: Tim Deegan <tim@xen.org> --- xen/arch/x86/hvm/hvm.c | 4 ++++ xen/arch/x86/hvm/rtc.c | 11 ++++++----- xen/include/public/hvm/params.h | 5 ++++- 3 files changed, 14 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index af249f7..e56ada5 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -4116,6 +4116,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) if ( a.value > SHUTDOWN_MAX ) rc = -EINVAL; break; + case HVM_PARAM_RTC_MODE: + if ( a.value > 1 ) + rc = -EINVAL; + break; } if ( rc == 0 ) diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c index cdedefe..4010d49 100644 --- a/xen/arch/x86/hvm/rtc.c +++ b/xen/arch/x86/hvm/rtc.c @@ -45,14 +45,15 @@ #define epoch_year 1900 #define get_year(x) (x + epoch_year) +/* This forms an ABI in HVM_PARAM_RTC_MODE */ enum rtc_mode { - rtc_mode_no_ack, - rtc_mode_strict + rtc_mode_no_ack = 0, + rtc_mode_strict = 1 }; -/* This must be in sync with how hvmloader sets the ACPI WAET flags. */ -#define mode_is(d, m) ((void)(d), rtc_mode_##m == rtc_mode_no_ack) -#define rtc_mode_is(s, m) mode_is(vrtc_domain(s), m) +#define rtc_mode_is(s, m) ( \ + vrtc_domain(s)->arch.hvm_domain.params[HVM_PARAM_RTC_MODE] \ + == rtc_mode_##m) static void rtc_copy_date(RTCState *s); static void rtc_set_time(RTCState *s); diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h index 517a184..2849dc3 100644 --- a/xen/include/public/hvm/params.h +++ b/xen/include/public/hvm/params.h @@ -145,6 +145,9 @@ /* SHUTDOWN_* action in case of a triple fault */ #define HVM_PARAM_TRIPLE_FAULT_REASON 31 -#define HVM_NR_PARAMS 32 +/* Set to 1 if domain is expected to use RTC no-ack optimisation */ +#define HVM_PARAM_RTC_MODE 32 + +#define HVM_NR_PARAMS 33 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */ -- 1.7.10.4
Andrew Cooper
2013-Nov-26 20:39 UTC
[PATCH 2/2] hvmloader: Allow the toolstack to choose WAET optimisations
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> CC: Keir Fraser <keir@xen.org> CC: Jan Beulich <JBeulich@suse.com> CC: Tim Deegan <tim@xen.org> CC: Ian Campbell <Ian.Campbell@citrix.com> CC: Ian Jackson <Ian.Jackson@eu.citrix.com> --- 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) ) + waet->flags |= ACPI_WAET_RTC_NO_ACK; + else + waet->flags &= ~ACPI_WAET_RTC_NO_ACK; + } + + s = xenstore_read("platform/waet-pm-reliable", NULL); + if ( s ) + { + if ( !strncmp(s, "1", 1) || !strncmp(s, "true", 4) ) + waet->flags |= ACPI_WAET_TIMER_ONE_READ; + else + waet->flags &= ~ACPI_WAET_TIMER_ONE_READ; + } + + printf("WAET flags: RTC noack %d, PM reliable %d\n", + !!(waet->flags & ACPI_WAET_RTC_NO_ACK), + !!(waet->flags & ACPI_WAET_TIMER_ONE_READ)); + set_checksum(waet, offsetof(struct acpi_header, checksum), sizeof(*waet)); + /* Inform Xen which RTC mode has been chosen */ + p.value = !!(waet->flags & ACPI_WAET_RTC_NO_ACK); + hypercall_hvm_op(HVMOP_set_param, &p); + return waet; } diff --git a/tools/firmware/hvmloader/acpi/static_tables.c b/tools/firmware/hvmloader/acpi/static_tables.c index 323ae31..5c699ba 100644 --- a/tools/firmware/hvmloader/acpi/static_tables.c +++ b/tools/firmware/hvmloader/acpi/static_tables.c @@ -136,16 +136,6 @@ struct acpi_20_rsdp Rsdp = { .length = sizeof(struct acpi_20_rsdp) }; -#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 */ - -/* - * The state of the RTC flag getting passed to the guest must be in - * sync with the mode selection in the hypervisor RTC emulation code. - */ -#define ACPI_WAET_FLAGS (ACPI_WAET_RTC_NO_ACK | \ - ACPI_WAET_TIMER_ONE_READ) - struct acpi_20_waet Waet = { .header = { .signature = ACPI_2_0_WAET_SIGNATURE, @@ -157,7 +147,7 @@ struct acpi_20_waet Waet = { .creator_id = ACPI_CREATOR_ID, .creator_revision = ACPI_CREATOR_REVISION }, - .flags = ACPI_WAET_FLAGS + .flags = ACPI_WAET_DEFAULT_FLAGS }; /* -- 1.7.10.4
Jan Beulich
2013-Nov-27 09:55 UTC
Re: [PATCH 1/2] x86/vRTC: Make rtc_mode_{strict, no_ack} a per-domain option
>>> On 26.11.13 at 21:39, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > +/* This forms an ABI in HVM_PARAM_RTC_MODE */Irrespective of this ...> enum rtc_mode { > - rtc_mode_no_ack, > - rtc_mode_strict > + rtc_mode_no_ack = 0, > + rtc_mode_strict = 1... this is a pointless change - the C specification requires them to be 0 and 1 respectively. There would be a point to this only if you added #define-s to the public interface (and used them here). Jan
Jan Beulich
2013-Nov-27 10:03 UTC
Re: [PATCH 2/2] hvmloader: Allow the toolstack to choose WAET optimisations
>>> On 26.11.13 at 21:39, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > @@ -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) ) > + waet->flags |= ACPI_WAET_RTC_NO_ACK; > + else > + waet->flags &= ~ACPI_WAET_RTC_NO_ACK; > + } > + > + s = xenstore_read("platform/waet-pm-reliable", NULL); > + if ( s ) > + { > + if ( !strncmp(s, "1", 1) || !strncmp(s, "true", 4) ) > + waet->flags |= ACPI_WAET_TIMER_ONE_READ; > + else > + waet->flags &= ~ACPI_WAET_TIMER_ONE_READ; > + }Nothing in this series really allows these to be easily controlled on a per-domain basis - I would have expected a config file flag... And for this second one, as hinted at in your overview mail, I don''t really see what purpose the controlling here serves: You don''t consume the setting, i.e. the sole effect is that of controlling the ACPI table''s flag value. Yet if we''re fine with the guest doing single reads (of whatever), then we''re surely fine too with it doing double reads. And hence the flag can easily be always set (as it was till now). If any second override was to be considered, I''d recommend on controlling the presence of the WAET as a whole. Jan
Andrew Cooper
2013-Nov-27 12:14 UTC
Re: [PATCH 2/2] hvmloader: Allow the toolstack to choose WAET optimisations
On 27/11/13 10:03, Jan Beulich wrote:>>>> On 26.11.13 at 21:39, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> @@ -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) ) >> + waet->flags |= ACPI_WAET_RTC_NO_ACK; >> + else >> + waet->flags &= ~ACPI_WAET_RTC_NO_ACK; >> + } >> + >> + s = xenstore_read("platform/waet-pm-reliable", NULL); >> + if ( s ) >> + { >> + if ( !strncmp(s, "1", 1) || !strncmp(s, "true", 4) ) >> + waet->flags |= ACPI_WAET_TIMER_ONE_READ; >> + else >> + waet->flags &= ~ACPI_WAET_TIMER_ONE_READ; >> + } > Nothing in this series really allows these to be easily controlled on a > per-domain basis - I would have expected a config file flag... > > And for this second one, as hinted at in your overview mail, I > don''t really see what purpose the controlling here serves: You > don''t consume the setting, i.e. the sole effect is that of > controlling the ACPI table''s flag value. Yet if we''re fine with > the guest doing single reads (of whatever), then we''re surely > fine too with it doing double reads. And hence the flag can > easily be always set (as it was till now). > > If any second override was to be considered, I''d recommend > on controlling the presence of the WAET as a whole. > > Jan >The setting is consumed using + /* Inform Xen which RTC mode has been chosen */ + p.value = !!(waet->flags & ACPI_WAET_RTC_NO_ACK); + hypercall_hvm_op(HVMOP_set_param, &p); Which changes the behaviour of rtc_mode_is(s, mode) in Xen. The presence (or lack thereof) of the WAET table does not address the problem at hand, which is that Xen''s current logic of trying to guess what the guest is doing WRT RTC is wrong. It causes the guest to fall into an infinite loop expecting standards compliment behaviour, where Xen has decided that the guest has moved to the optimised behaviour. ~Andrew
Jan Beulich
2013-Nov-27 12:56 UTC
Re: [PATCH 2/2] hvmloader: Allow the toolstack to choose WAET optimisations
>>> On 27.11.13 at 13:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 27/11/13 10:03, Jan Beulich wrote: >>>>> On 26.11.13 at 21:39, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >>> @@ -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) ) >>> + waet->flags |= ACPI_WAET_RTC_NO_ACK; >>> + else >>> + waet->flags &= ~ACPI_WAET_RTC_NO_ACK; >>> + } >>> + >>> + s = xenstore_read("platform/waet-pm-reliable", NULL); >>> + if ( s ) >>> + { >>> + if ( !strncmp(s, "1", 1) || !strncmp(s, "true", 4) ) >>> + waet->flags |= ACPI_WAET_TIMER_ONE_READ; >>> + else >>> + waet->flags &= ~ACPI_WAET_TIMER_ONE_READ; >>> + } >> Nothing in this series really allows these to be easily controlled on a >> per-domain basis - I would have expected a config file flag... >> >> And for this second one, as hinted at in your overview mail, I >> don''t really see what purpose the controlling here serves: You >> don''t consume the setting, i.e. the sole effect is that of >> controlling the ACPI table''s flag value. Yet if we''re fine with >> the guest doing single reads (of whatever), then we''re surely >> fine too with it doing double reads. And hence the flag can >> easily be always set (as it was till now). >> >> If any second override was to be considered, I''d recommend >> on controlling the presence of the WAET as a whole. > > The setting is consumed using > > + /* Inform Xen which RTC mode has been chosen */ > + p.value = !!(waet->flags & ACPI_WAET_RTC_NO_ACK); > + hypercall_hvm_op(HVMOP_set_param, &p);Note that I said "this second one", i.e. referring to ACPI_WAET_TIMER_ONE_READ. Jan
Andrew Cooper
2013-Nov-27 12:58 UTC
Re: [PATCH 2/2] hvmloader: Allow the toolstack to choose WAET optimisations
On 27/11/13 12:56, Jan Beulich wrote:>>>> On 27.11.13 at 13:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> On 27/11/13 10:03, Jan Beulich wrote: >>>>>> On 26.11.13 at 21:39, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >>>> @@ -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) ) >>>> + waet->flags |= ACPI_WAET_RTC_NO_ACK; >>>> + else >>>> + waet->flags &= ~ACPI_WAET_RTC_NO_ACK; >>>> + } >>>> + >>>> + s = xenstore_read("platform/waet-pm-reliable", NULL); >>>> + if ( s ) >>>> + { >>>> + if ( !strncmp(s, "1", 1) || !strncmp(s, "true", 4) ) >>>> + waet->flags |= ACPI_WAET_TIMER_ONE_READ; >>>> + else >>>> + waet->flags &= ~ACPI_WAET_TIMER_ONE_READ; >>>> + } >>> Nothing in this series really allows these to be easily controlled on a >>> per-domain basis - I would have expected a config file flag... >>> >>> And for this second one, as hinted at in your overview mail, I >>> don''t really see what purpose the controlling here serves: You >>> don''t consume the setting, i.e. the sole effect is that of >>> controlling the ACPI table''s flag value. Yet if we''re fine with >>> the guest doing single reads (of whatever), then we''re surely >>> fine too with it doing double reads. And hence the flag can >>> easily be always set (as it was till now). >>> >>> If any second override was to be considered, I''d recommend >>> on controlling the presence of the WAET as a whole. >> The setting is consumed using >> >> + /* Inform Xen which RTC mode has been chosen */ >> + p.value = !!(waet->flags & ACPI_WAET_RTC_NO_ACK); >> + hypercall_hvm_op(HVMOP_set_param, &p); > Note that I said "this second one", i.e. referring to > ACPI_WAET_TIMER_ONE_READ. > > Jan >Ah apologies - I missed that. I did bring that up in the covering letter as to whether it was worth having an option for it in the first place. ~Andrew
Tim Deegan
2013-Nov-28 10:45 UTC
Re: [PATCH 1/2] x86/vRTC: Make rtc_mode_{strict, no_ack} a per-domain option
At 09:55 +0000 on 27 Nov (1385542548), Jan Beulich wrote:> >>> On 26.11.13 at 21:39, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > > +/* This forms an ABI in HVM_PARAM_RTC_MODE */ > > Irrespective of this ... > > > enum rtc_mode { > > - rtc_mode_no_ack, > > - rtc_mode_strict > > + rtc_mode_no_ack = 0, > > + rtc_mode_strict = 1 > > ... this is a pointless change - the C specification requires them to > be 0 and 1 respectively. There would be a point to this only if you > added #define-s to the public interface (and used them here).I think that''s a good idea -- the code assumes that the toolstack''s choice of 0 and 1 match this enum, so it should be made explicit here (so later engineers don''t reshuffle the enum for some reason). Tim.
Ian Campbell
2013-Nov-29 09:53 UTC
Re: [PATCH 2/2] hvmloader: Allow the toolstack to choose WAET optimisations
On Tue, 2013-11-26 at 20:39 +0000, Andrew Cooper wrote:> + s = xenstore_read("platform/waet-rtc-noack", NULL);[...]> + s = xenstore_read("platform/waet-pm-reliable", NULL);What writes these? Is the default in their absence sane? Ian.
Ian Campbell
2013-Nov-29 09:55 UTC
Re: [PATCH 2/2] hvmloader: Allow the toolstack to choose WAET optimisations
On Tue, 2013-11-26 at 20:39 +0000, Andrew Cooper wrote:> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> > CC: Keir Fraser <keir@xen.org> > CC: Jan Beulich <JBeulich@suse.com> > CC: Tim Deegan <tim@xen.org> > CC: Ian Campbell <Ian.Campbell@citrix.com> > CC: Ian Jackson <Ian.Jackson@eu.citrix.com> > --- > 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.
Andrew Cooper
2013-Nov-29 10:57 UTC
Re: [PATCH 2/2] hvmloader: Allow the toolstack to choose WAET optimisations
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@citrix.com> >> CC: Keir Fraser <keir@xen.org> >> CC: Jan Beulich <JBeulich@suse.com> >> CC: Tim Deegan <tim@xen.org> >> CC: Ian Campbell <Ian.Campbell@citrix.com> >> CC: Ian Jackson <Ian.Jackson@eu.citrix.com> >> --- >> 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. 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 In my copious free time, I was going to formally introduce "xenstore_read_bool()" in hvmloader. ~Andrew
Ian Campbell
2013-Nov-29 11:01 UTC
Re: [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@citrix.com> > >> CC: Keir Fraser <keir@xen.org> > >> CC: Jan Beulich <JBeulich@suse.com> > >> CC: Tim Deegan <tim@xen.org> > >> CC: Ian Campbell <Ian.Campbell@citrix.com> > >> CC: Ian Jackson <Ian.Jackson@eu.citrix.com> > >> --- > >> 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''sRegardless, 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