On 2013-11-06 16:08, Aneesh Kumar K.V wrote:
> Jan Kiszka <jan.kis...@siemens.com> writes:
>
>> On 2013-10-07 18:53, Aneesh Kumar K.V wrote:
>>> From: "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com>
>>>
>>> Targets like ppc64 support different typed of KVM, one which use
>>> hypervisor mode and the other which doesn't. Add a new machine
>>> property kvm_type that helps in selecting the respective ones
>>> We also add a new QEMUMachine callback get_vm_type that helps
>>> in mapping the string representation of kvm type specified.
>>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com>
>>
>> ...
>>
>>> diff --git a/vl.c b/vl.c
>>> index 4e709d5..7ecc581 100644
>>> --- a/vl.c
>>> +++ b/vl.c
>>> @@ -427,7 +427,12 @@ static QemuOptsList qemu_machine_opts = {
>>> .name = "usb",
>>> .type = QEMU_OPT_BOOL,
>>> .help = "Set on/off to enable/disable usb",
>>> + },{
>>> + .name = "kvm_type",
>>> + .type = QEMU_OPT_STRING,
>>> + .help = "Set to kvm type to be used in create vm ioctl",
>>
>> This does not sound like an appropriate documentation for an enduser.
>>
>
> Any other suggestion for that ? It is actually a string which will be
> parsed by the machine opt callback, and the return value is used as the
> argument to create vm ioctl.
Maybe something like this: "Specifies the KVM virtualization mode (xxx,
yyy, whatever)"
No user is interesting in how this information gets transfered to the
KVM core. That's an irrelavant implementation detail.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
