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

[Alexey Kardashevskiy]

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 <address@hidden>
> > ---
> >   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