qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [PATCH qemu RFC 3/4] spapr: Advertise H_RTAS to the guest
Date: Tue, 23 Jul 2019 17:41:11 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0



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 <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?


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]