On Tue, Dec 04, 2018 at 02:53:26PM +0100, Paolo Bonzini wrote: > 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
It isn't too bad, you just include a driver and then it's happy. Isn't a device just for panic going too far though? Should it be some kind of PV device that we can use to add more pv stuff in the future, with a panic option? -- MST