Amit Shah wrote:
> * On Wednesday 24 Sep 2008 14:08:14 Han, Weidong wrote:
>> Amit Shah wrote:
>>> * On Wednesday 24 Sep 2008 13:21:25 Han, Weidong wrote:
>>>> Amit Shah wrote:
>>>>>>         - Add dummy driver to hide/unbind passthrough device from
>>>>>> host kernel
>>>>> 
>>>>> This isn't needed; we currently don't assign the device to the
>>>>> guest if we find that a driver is already loaded. I intend to
>>>>> change it to failing guest start altogether in case we find a
>>>>> module already using a device. When a guest exits, we release all
>>>>> the structures and hence even unloading kvm is not needed to
>>>>> reclaim the device on the host side.
>>>> 
>>>> This task needn't targe 2.6.28. For long term, we need it to make
>>>> device assignment more user friendly.
>>> 
>>> How is the current scheme not user friendly? Or, how will adding a
>>> "dummy driver" be more user friendly?
>> 
>> We had some discussion on this few months ago. Currently, users need
>> to remove device driver before assignment. If there are more than
>> one same type devices, removing driver makes them cannot work at the
>> same time, even though user just want to assign one of them to
>> guest. Note that not all drivers support unbind function. If we can
>> provide a mechanism to hide single device independently, e.g,
>> implement a dummy driver to own devices that user want to assign to
>> guest. I think it's more friendly to end user than remove/unbind
>> driver manually. 
> 
> This needs a change in the driver core and it definitely won't be
> solved by having a dummy device. We have to have a way to signal to
> modules that a particular device will now be owned by a different
> module, even if the current module thinks it is the sole owner.

The assigned devices are only owned by the dummy driver. Like Xen,
pciback owns the assignable devices via adding option
'pciback.hide=(bus:dev:func)' in grub, that means device(bus:dev:func)
driver won't be loaded. Then user can assign these hidden devices. 

Randy (Weidong)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to