Message ID | 1490865209-18283-9-git-send-email-Wei.Chen@arm.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Hi Wei, On 30/03/17 10:13, Wei Chen wrote: > In order to distinguish guest-generated SErrors from hypervisor-generated > SErrors we have to place SError checking code in every EL1 -> EL2 paths. > That will cause overhead on entries due to dsb/isb. > > However, not all platforms want to categorize SErrors. For example, a host > that is running with trusted guests. The administrator can confirm that > all guests that are running on the host will not trigger such SErrors. In > this user-case, we should provide some options to administrators to avoid s/user-case/use-case/ > +### serrors (ARM) > +> `= diverse | forward | panic` > + > +> Default: `diverse` > + > +This parameter is provided to administrators to determine how the > +hypervisors handle SErrors. > + > +In order to distinguish guest-generated SErrors from hypervisor-generated > +SErrors we have to place SError checking code in every EL1 -> EL2 paths. > +That will cause overhead on entries due to dsb/isb. However, not all platforms s/entries/entries and exits/ I think because none of the options you provide will effectively only do dsb/isb on entries. Cheers,
Hi Julien, On 2017/3/31 1:39, Julien Grall wrote: > Hi Wei, > > On 30/03/17 10:13, Wei Chen wrote: >> In order to distinguish guest-generated SErrors from hypervisor-generated >> SErrors we have to place SError checking code in every EL1 -> EL2 paths. >> That will cause overhead on entries due to dsb/isb. >> >> However, not all platforms want to categorize SErrors. For example, a host >> that is running with trusted guests. The administrator can confirm that >> all guests that are running on the host will not trigger such SErrors. In >> this user-case, we should provide some options to administrators to avoid > > s/user-case/use-case/ > >> +### serrors (ARM) >> +> `= diverse | forward | panic` >> + >> +> Default: `diverse` >> + >> +This parameter is provided to administrators to determine how the >> +hypervisors handle SErrors. >> + >> +In order to distinguish guest-generated SErrors from hypervisor-generated >> +SErrors we have to place SError checking code in every EL1 -> EL2 paths. >> +That will cause overhead on entries due to dsb/isb. However, not all platforms > > s/entries/entries and exits/ I think because none of the options you > provide will effectively only do dsb/isb on entries. > Yes, the options will affect both entries and exits. I would update the commit message and doc. > Cheers, >
diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index bdbdb8a..6d395c5 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -1474,6 +1474,49 @@ enabling more sockets and cores to go into deeper sleep states. Set the serial transmit buffer size. +### serrors (ARM) +> `= diverse | forward | panic` + +> Default: `diverse` + +This parameter is provided to administrators to determine how the +hypervisors handle SErrors. + +In order to distinguish guest-generated SErrors from hypervisor-generated +SErrors we have to place SError checking code in every EL1 -> EL2 paths. +That will cause overhead on entries due to dsb/isb. However, not all platforms +need to categorize SErrors. For example, a host that is running with trusted +guests. The administrator can confirm that all guests that are running on the +host will not trigger such SErrors. In this case, the administrator can use +this parameter to skip categorizing SErrors and reduce the overhead of dsb/isb. + +We provided the following 3 options to administrators to determine how the +hypervisors handle SErrors: + +* `diverse`: + The hypervisor will distinguish guest SErrors from hypervisor SErrors. + The guest generated SErrors will be forwarded to guests, the hypervisor + generated SErrors will cause the whole system to crash. + It requires: + 1. dsb/isb on all EL1 -> EL2 trap entries to categorize SErrors correctly. + 2. dsb/isb on EL2 -> EL1 return paths to prevent slipping hypervisor + SErrors to guests. + 3. dsb/isb in context switch to isolate SErrors between 2 vCPUs. + +* `forward`: + The hypervisor will not distinguish guest SErrors from hypervisor SErrors. + All SErrors will be forwarded to guests, except the SErrors generated when + the idle vCPU is running. The idle domain doesn't have the ability to handle + SErrors, so we have to crash the whole system when we get SErros with the + idle vCPU. This option will avoid most overhead of the dsb/isb, except the + dsb/isb in context switch which is used to isolate the SErrors between 2 + vCPUs. + +* `panic`: + The hypervisor will not distinguish guest SErrors from hypervisor SErrors. + All SErrors will crash the whole system. This option will avoid all overhead + of the dsb/isb pairs. + ### smap > `= <boolean> | hvm` diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 7850115..955d97c 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -101,6 +101,25 @@ static int debug_stack_lines = 40; integer_param("debug_stack_lines", debug_stack_lines); +static enum { + SERRORS_DIVERSE, + SERRORS_FORWARD, + SERRORS_PANIC, +} serrors_op; + +static void __init parse_serrors_behavior(const char *str) +{ + if ( !strcmp(str, "forward") ) + serrors_op = SERRORS_FORWARD; + else if ( !strcmp(str, "panic") ) + serrors_op = SERRORS_PANIC; + else + serrors_op = SERRORS_DIVERSE; + + return; +} +custom_param("serrors", parse_serrors_behavior); + void init_traps(void) { /* Setup Hyp vector base */