[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH qemu RFC 3/4] spapr: Advertise H_RTAS to the gue
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [PATCH qemu RFC 3/4] spapr: Advertise H_RTAS to the guest |
Date: |
Tue, 23 Jul 2019 16:14:43 +1000 |
User-agent: |
Mutt/1.12.0 (2019-05-25) |
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 <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,
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
signature.asc
Description: PGP signature
[Qemu-devel] [PATCH qemu RFC 1/4] spapr: Allow changing kernel loading address, Alexey Kardashevskiy, 2019/07/19
[Qemu-devel] [PATCH qemu RFC 2/4] spapr: Allow bios-less configuration, Alexey Kardashevskiy, 2019/07/19
[Qemu-devel] [PATCH qemu RFC 4/4] spapr: Implement SLOF-less client_architecture_support, Alexey Kardashevskiy, 2019/07/19