| Message ID | 20190720012850.14369-4-aik@ozlabs.ru |
|---|---|
| State | New |
| Headers | show |
| Series | spapr: Kexec style boot | expand |
On Sat, Jul 20, 2019 at 11:28:49AM +1000, Alexey Kardashevskiy wrote: > Since day 1 QEMU implemented RTAS as a custom hypercall wrapped into > a small 20 bytes blob which guest would call to enter RTAS. Although > it works fine, it is still a separate binary image which requires signing > at no additional benefit. > > This adds a flag into /chosen to tell a modified guest that if the flag > is there, it can call H_RTAS directly and avoid calling into the RTAS > blob. > > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> > --- > hw/ppc/spapr.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > index 81ad6a6f28de..b097a99951f1 100644 > --- a/hw/ppc/spapr.c > +++ b/hw/ppc/spapr.c > @@ -1230,6 +1230,9 @@ static void spapr_dt_chosen(SpaprMachineState *spapr, void *fdt) > _FDT(fdt_setprop_cell(fdt, chosen, "linux,pci-probe-only", 0)); > } > > + /* We always implemented RTAS as hcall, tell guests to call it directly */ > + _FDT(fdt_setprop_cell(fdt, chosen, "qemu,h_rtas", 1)); Rather than creating a new property for this we could use the qemu,hypertas-functions property which is already used to advertise some KVM specific hcalls. > spapr_dt_ov5_platform_support(spapr, fdt, chosen); > > g_free(stdout_path);
On 23/07/2019 13:53, David Gibson wrote: > On Sat, Jul 20, 2019 at 11:28:49AM +1000, Alexey Kardashevskiy wrote: >> Since day 1 QEMU implemented RTAS as a custom hypercall wrapped into >> a small 20 bytes blob which guest would call to enter RTAS. Although >> it works fine, it is still a separate binary image which requires signing >> at no additional benefit. >> >> This adds a flag into /chosen to tell a modified guest that if the flag >> is there, it can call H_RTAS directly and avoid calling into the RTAS >> blob. >> >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> >> --- >> hw/ppc/spapr.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c >> index 81ad6a6f28de..b097a99951f1 100644 >> --- a/hw/ppc/spapr.c >> +++ b/hw/ppc/spapr.c >> @@ -1230,6 +1230,9 @@ static void spapr_dt_chosen(SpaprMachineState *spapr, void *fdt) >> _FDT(fdt_setprop_cell(fdt, chosen, "linux,pci-probe-only", 0)); >> } >> >> + /* We always implemented RTAS as hcall, tell guests to call it directly */ >> + _FDT(fdt_setprop_cell(fdt, chosen, "qemu,h_rtas", 1)); > > Rather than creating a new property for this we could use the > qemu,hypertas-functions property which is already used to advertise > some KVM specific hcalls. True, this is another way of doing it. We will also need a proper number for it rather that custom 0xf000, Paul suggested we could tell the guest this number via the "qemu,h_rtas" property. > >> spapr_dt_ov5_platform_support(spapr, fdt, chosen); >> >> g_free(stdout_path); >
On Tue, Jul 23, 2019 at 03:48:34PM +1000, Alexey Kardashevskiy wrote: > > > On 23/07/2019 13:53, David Gibson wrote: > > On Sat, Jul 20, 2019 at 11:28:49AM +1000, Alexey Kardashevskiy wrote: > > > Since day 1 QEMU implemented RTAS as a custom hypercall wrapped into > > > a small 20 bytes blob which guest would call to enter RTAS. Although > > > it works fine, it is still a separate binary image which requires signing > > > at no additional benefit. > > > > > > This adds a flag into /chosen to tell a modified guest that if the flag > > > is there, it can call H_RTAS directly and avoid calling into the RTAS > > > blob. > > > > > > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> > > > --- > > > hw/ppc/spapr.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > > > index 81ad6a6f28de..b097a99951f1 100644 > > > --- a/hw/ppc/spapr.c > > > +++ b/hw/ppc/spapr.c > > > @@ -1230,6 +1230,9 @@ static void spapr_dt_chosen(SpaprMachineState *spapr, void *fdt) > > > _FDT(fdt_setprop_cell(fdt, chosen, "linux,pci-probe-only", 0)); > > > } > > > + /* We always implemented RTAS as hcall, tell guests to call it directly */ > > > + _FDT(fdt_setprop_cell(fdt, chosen, "qemu,h_rtas", 1)); > > > > Rather than creating a new property for this we could use the > > qemu,hypertas-functions property which is already used to advertise > > some KVM specific hcalls. > > True, this is another way of doing it. We will also need a proper number for > it rather that custom 0xf000, So, I take from this you're considering making this a supported method of operation, maybe even incorporating it into PAPR? > Paul suggested we could tell the guest this > number via the "qemu,h_rtas" property. Hm, we could, but introducing dynamic hypercall numbers for this seems an odd thing to do; both PAPR standardized and qemu specific hypercalls we currently operate on the guest just knowing the numbers. It seems to me that the obvious way to handle this is to have a tag in qemu,hypertas-functions which indicates the presence of the existing 0xf00 H_RTAS. If/when we have a PAPR (or pseudo-PAPR) standardized number, that would get a tag in ibm,hypertas-functions to advertise it.
On 23/07/2019 16:14, David Gibson wrote: > On Tue, Jul 23, 2019 at 03:48:34PM +1000, Alexey Kardashevskiy wrote: >> >> >> On 23/07/2019 13:53, David Gibson wrote: >>> On Sat, Jul 20, 2019 at 11:28:49AM +1000, Alexey Kardashevskiy wrote: >>>> Since day 1 QEMU implemented RTAS as a custom hypercall wrapped into >>>> a small 20 bytes blob which guest would call to enter RTAS. Although >>>> it works fine, it is still a separate binary image which requires signing >>>> at no additional benefit. >>>> >>>> This adds a flag into /chosen to tell a modified guest that if the flag >>>> is there, it can call H_RTAS directly and avoid calling into the RTAS >>>> blob. >>>> >>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> >>>> --- >>>> hw/ppc/spapr.c | 3 +++ >>>> 1 file changed, 3 insertions(+) >>>> >>>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c >>>> index 81ad6a6f28de..b097a99951f1 100644 >>>> --- a/hw/ppc/spapr.c >>>> +++ b/hw/ppc/spapr.c >>>> @@ -1230,6 +1230,9 @@ static void spapr_dt_chosen(SpaprMachineState *spapr, void *fdt) >>>> _FDT(fdt_setprop_cell(fdt, chosen, "linux,pci-probe-only", 0)); >>>> } >>>> + /* We always implemented RTAS as hcall, tell guests to call it directly */ >>>> + _FDT(fdt_setprop_cell(fdt, chosen, "qemu,h_rtas", 1)); >>> >>> Rather than creating a new property for this we could use the >>> qemu,hypertas-functions property which is already used to advertise >>> some KVM specific hcalls. >> >> True, this is another way of doing it. We will also need a proper number for >> it rather that custom 0xf000, > > So, I take from this you're considering making this a supported method > of operation, maybe even incorporating it into PAPR? This was discussed as well since we are adding things in this area anyway (there is instantiate-rtas-64 coming), we could add this H_RTAS too. >> Paul suggested we could tell the guest this >> number via the "qemu,h_rtas" property. > > Hm, we could, but introducing dynamic hypercall numbers for this seems > an odd thing to do; both PAPR standardized and qemu specific > hypercalls we currently operate on the guest just knowing the numbers. > > It seems to me that the obvious way to handle this is to have a tag in > qemu,hypertas-functions which indicates the presence of the existing > 0xf00 H_RTAS. If/when we have a PAPR (or pseudo-PAPR) standardized > number, that would get a tag in ibm,hypertas-functions to advertise > it. Makes sense to me, will update.
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 81ad6a6f28de..b097a99951f1 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -1230,6 +1230,9 @@ static void spapr_dt_chosen(SpaprMachineState *spapr, void *fdt) _FDT(fdt_setprop_cell(fdt, chosen, "linux,pci-probe-only", 0)); } + /* We always implemented RTAS as hcall, tell guests to call it directly */ + _FDT(fdt_setprop_cell(fdt, chosen, "qemu,h_rtas", 1)); + spapr_dt_ov5_platform_support(spapr, fdt, chosen); g_free(stdout_path);
Since day 1 QEMU implemented RTAS as a custom hypercall wrapped into a small 20 bytes blob which guest would call to enter RTAS. Although it works fine, it is still a separate binary image which requires signing at no additional benefit. This adds a flag into /chosen to tell a modified guest that if the flag is there, it can call H_RTAS directly and avoid calling into the RTAS blob. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> --- hw/ppc/spapr.c | 3 +++ 1 file changed, 3 insertions(+)