spapr: Kexec style boot

[Qemu-devel] [PATCH qemu RFC 3/4] spapr: Advertise H_RTAS to the guest

Posted by Alexey Kardashevskiy 6 years, 3 months ago

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));
+
     spapr_dt_ov5_platform_support(spapr, fdt, chosen);
 
     g_free(stdout_path);
-- 
2.17.1

Re: [Qemu-devel] [PATCH qemu RFC 3/4] spapr: Advertise H_RTAS to the guest

Posted by David Gibson 6 years, 3 months ago

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);

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [PATCH qemu RFC 3/4] spapr: Advertise H_RTAS to the guest

Posted by Alexey Kardashevskiy 6 years, 3 months ago


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);
> 

-- 
Alexey

Re: [Qemu-devel] [PATCH qemu RFC 3/4] spapr: Advertise H_RTAS to the guest

Posted by David Gibson 6 years, 3 months ago

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.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [PATCH qemu RFC 3/4] spapr: Advertise H_RTAS to the guest

Posted by Alexey Kardashevskiy 6 years, 3 months ago


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.


-- 
Alexey