Re: [RFC/PATCH 15/15] guest: virtio device support, and kvm hypercalls

[Christian Borntraeger <borntraeger@de.ibm.com>]

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