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
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
