On 1/23/19 11:26 AM, Paul Mackerras wrote: > On Wed, Jan 23, 2019 at 09:48:31AM +0100, Cédric Le Goater wrote: >> On 1/23/19 7:44 AM, Benjamin Herrenschmidt wrote: >>> On Tue, 2019-01-22 at 16:23 +1100, Paul Mackerras wrote: >>>> Why do we need to provide real-mode versions of these hypercall >>>> handlers? I thought these hypercalls would only get called >>>> infrequently, and in any case certainly much less frequently than once >>>> per interrupt delivered. If they are infrequent, then let's leave out >>>> the real-mode version and just handle them in book3s_hv.c. >>> >>> Agreed with the exception maybe of H_INT_ESB >> >> ok. >> >> Some of these hcalls are really simple and only getting local info from >> the host (h_int_get_*). I thought handling the hcall ASAP was a preferred >> practice, even if the hcall is not called frequently. Isn't it ? > > If we are going to handle a given hcall in the kernel at all, then we > have to have a virtual mode handler. If we have a real-mode handler > as well then we in general incur a certain amount of code duplication > with consequent maintenance costs and possibility of bugs. So we > generally only have real-mode handlers for the hcalls where it is > critical to minimize the latency. From what Ben is saying that would > only be H_INT_ESB, and maybe not even that. ok. and yes, even the H_INT_ESB is questionable as this is really a rare configuration. > If H_INT_ESB is only used for LSIs, then is a guest going to be using > it at all? My understanding was that with XIVE, only a small number > of interrupts that are to do with system management functions are > LSIs; all of the interrupts relating to PCI-e devices are MSIs. So do > we actually have a real high-frequency use case for LSIs in a guest? The guest should be using a rtl8139 or a e1000 NIC under QEMU/KVM, which is not the common scenario. > For now I would prefer that you remove all the real-mode hcall > handlers. We can add them later if we get performance data showing > that they are needed. ok. I will. > Regarding whether or not to have a given hcall handler in the kernel > at all - if there is for example an hcall which is just called once > on guest startup, and its function is just to provide information to > the guest, and QEMU has that information, then why not have that hcall > implemented by QEMU? Are any of the hcalls like that? > > For example, if H_INT_GET_SOURCE_INFO was implemented in QEMU, could > we then remove the VC_BASE thing from the xive device? Yes. H_INT_GET_SOURCE_INFO looks like a good candidate, all info should be in QEMU and there are no OPAL calls, and we would get rid of the VC_BASE kvm device ioctl at the same time. Thanks, C.
