On 04.02.15 02:32, David Gibson wrote:
> On Wed, Feb 04, 2015 at 08:19:06AM +1100, Paul Mackerras wrote:
>> On Tue, Feb 03, 2015 at 05:10:51PM +1100, David Gibson wrote:
>>> qemu currently implements the hypercalls H_LOGICAL_CI_LOAD and
>>> H_LOGICAL_CI_STORE as PAPR extensions. These are used by the SLOF firmware
>>> for IO, because performing cache inhibited MMIO accesses with the MMU off
>>> (real mode) is very awkward on POWER.
>>>
>>> This approach breaks when SLOF needs to access IO devices implemented
>>> within KVM instead of in qemu. The simplest example would be virtio-blk
>>> using an iothread, because the iothread / dataplane mechanism relies on
>>> an in-kernel implementation of the virtio queue notification MMIO.
>>>
>>> To fix this, an in-kernel implementation of these hypercalls has been made,
>>> however, the hypercalls still need to be enabled from qemu. This performs
>>> the necessary calls to do so.
>>>
>>> Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
>>
>> [snip]
>>
>>> + ret1 = kvmppc_enable_hcall(kvm_state, H_LOGICAL_CI_LOAD);
>>> + if (ret1 != 0) {
>>> + fprintf(stderr, "Warning: error enabling H_LOGICAL_CI_LOAD in KVM:"
>>> + " %s\n", strerror(errno));
>>> + }
>>> +
>>> + ret2 = kvmppc_enable_hcall(kvm_state, H_LOGICAL_CI_STORE);
>>> + if (ret2 != 0) {
>>> + fprintf(stderr, "Warning: error enabling H_LOGICAL_CI_STORE in
>>> KVM:"
>>> + " %s\n", strerror(errno));
>>> + }
>>> +
>>> + if ((ret1 != 0) || (ret2 != 0)) {
>>> + fprintf(stderr, "Warning: Couldn't enable H_LOGICAL_CI_* in KVM,
>>> SLOF"
>>> + " may be unable to operate devices with in-kernel
>>> emulation\n");
>>> + }
>>
>> You'll always get these warnings if you're running on an old (meaning
>> current upstream) kernel, which could be annoying.
>
> True.
>
>> Is there any way
>> to tell whether you have configured any devices which need the
>> in-kernel MMIO emulation and only warn if you have?
>
> In theory, I guess so. In practice I can't see how you'd enumerate
> all devices that might require kernel intervention without something
> horribly invasive.
We could WARN_ONCE in QEMU if we emulate such a hypercall, but its
handler is io_mem_unassigned (or we add another minimum priority huge
memory region on all 64bits of address space that reports the breakage).
Alex
