qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] [Qemu-devel] [PATCH V11 0/8] add pvpanic mmio support


From: Paolo Bonzini
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH V11 0/8] add pvpanic mmio support
Date: Tue, 4 Dec 2018 14:53:26 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 04/12/18 14:43, Peter Maydell wrote:
> The point about PCI is that it is the same everywhere and
> discoverable, and easy for the user to add to the system or not.
> MMIO requires extra work for every board model that we want to
> put the device into, plus extra on both kernel and QEMU side
> for every system description mechanism (ACPI, dtb, whatever
> some future architecture might use), even if we have the basic
> "mmio pvpanic" device code already.

Looks like dtb is becoming a standard?  Even RISC-V switched from their
own system description to device tree.  Anyway, this is not too
important.  I agree with you about discoverability, on the other hand if
we could have something defined by the vendor rather than QEMU it would
be even better.  (Even better would be something that distro kernels
already have support for, but that would be asking too much probably).

>> Also, while reusing code in general is nice, sometimes there are
>> platform-specific ways to do it.  For ARM, for example, would it make
>> sense to use an HVC/SMC that "extends" the PSCI, and pass the number in
>> the PSCI device tree node?
> 
> If you want a hypercall then these days the arm HVC calling convention
> includes mechanisms for discoverably determining whether a particular
> hypercall is supported, so you wouldn't need to pass anything in the
> ACPI or dtb. But I didn't get the impression that anybody wanted a
> hypercall for this particularly.

Not for x86, where each hypervisor has its own hypercall number and even
its calling convention.  But for ARM it already makes more sense.

>> Related to this, is there a more or less "standard" watchdog device on
>> ARM that could be added to virt?  There is the SBSA watchdog, but it's
>> ugly for implementation in KVM because it counts down with frequency
>> equal to CNTFRQ (which I'm not sure if QEMU has access too, and also it
>> doesn't play well with live migration).
> 
> The i6300esb is PCI, presumably that would work?

Yeah, I was wondering if there was something in PrimeCell.  I found
SP805 exists now.

>>> I notice also that there's a mention in that thread that the pvpanic
>>> ACPI table entry on x86 resulted in unhelpful Windows notifications
>>> about new devices it didn't understand. Is that going to be an issue
>>> for Arm with this mmio pvpanic ?
>>
>> Yes, it is probably the same as for x86.
> 
> I guess we need to find out if that is a problem before we can
> merge this, then.

As long as the pvpanic device is not added by default it's okay.

Paolo



reply via email to

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