On 18/12/2018 11:50, Greg Kurz wrote: > On Tue, 18 Dec 2018 11:00:01 +0100 > Laurent Vivier <lviv...@redhat.com> wrote: > >> On 18/12/2018 10:23, Greg Kurz wrote: >>> On Tue, 18 Dec 2018 08:50:00 +0100 ... >>> Also, even if linux only seems to call this with 0x1, this is a >>> limitation from a LoPAPR standpoint. Not sure H_PARAMETER is the >>> appropriate return value if flags is 0x2 since the guest did >>> nothing wrong... I'd rather return H_FUNCTION in this case. >> >> The doc says: >> >> H_Function: The function is not supported >> H_Parameter: Unsupported flag parameter value >> >> in that case function is supported but not the flag, so I think >> H_PARAMETER is a better choice. >> > > Well... neither LoPAPR, nor IBM confidential PAPR+ do say anything > about partial support for this hcall. If the guest was to use the > flags == 0x2 variant, eg, some closed-source OS supporting PAPR, > it could be legitimately confused to get an H_PARAMETER error when > passing supposedly valid parameters... how to cope with that ? > On the other hand, if QEMU cannot honor the flags == 0x2 variant > and returns H_FUNCTION then the OS can recover since it is > required by the specification.
You have certainly access to more information than I have, so I'll change H_PARAMETER to H_FUNCTION. Thanks, Laurent
