Am Freitag, 21. März 2008 schrieb Rusty Russell: > I'd recommend a hypercall after set_status, as well as reset. The > reason lguest doesn't do this is that we don't do feature negotiation > (assuming guest kernel matches host kernel). In general, the host > needs to know when the VIRTIO_CONFIG_S_DRIVER_OK is set so it can see > what features the guest driver accepted.
Right. Will have a look. > > Overloading the notify hypercall is kind of a hack too, but it works so > no real need to change that. > > > + * The root device for the kvm virtio devices. > > + * This makes them appear as /sys/devices/kvm/0,1,2 not /sys/devices/0,1,2. > > + */ > > +static struct device kvm_root = { > > + .parent = NULL, > > + .bus_id = "kvm_s390", > > +}; > > You mean /sys/devices/kvm_s390/0,1,2? Yes, thanks. > > > +static int __init kvm_devices_init(void) > > +{ > > + if (!MACHINE_IS_KVM) > > + return -ENODEV; > > + > > + if (device_register(&kvm_root) != 0) > > + panic("Could not register kvm root"); > > + > > + if (add_shared_memory((max_pfn) << PAGE_SHIFT, PAGE_SIZE)) { > > + device_unregister(&kvm_root); > > + return -ENOMEM; > > + } > > Hmm, panic on device_register fail, but -ENOMEM on add_shared_memory fail? > My theory was that since this is boot time, panic() is the right thing. Good spot, but I agree with Carsten. Drivers should not panic. I have module load/unload capability on my long term todo list, but I can change the panic now. Christian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel