Freeze with KVM_CLOCK, undocumented dependency VIRTIO_BLK -> VIRTIO_PCI

Freeze with KVM_CLOCK, undocumented dependency VIRTIO_BLK -> VIRTIO_PCI

[Bernhard Schmidt]

Hi,

apologies if those questions have already been answered, I did not find
anything specific that should still be visible.

I'm currently testing KVM (kvm-0.70 package from Debian unstable,
rebuilt on Ubuntu Hardy) on a Athlon64 in i386 mode and found two small
issues while trying to build a small kernel for my guest systems
(2.6.26-rc6).

a) when I enable KVM_CLOCK in the kernel configuration the guest system
freezes after

PCI: Found IRQ 11 for device 0000:00:04.0
 vda: vda1 vda2
TCP cubic registered
NET: Registered protocol family 10
NET: Registered protocol family 17
Using IPI Shortcut mode

when I disable KVM_CLOCK it mounts the filesystem and boots just fine

Using IPI Shortcut mode
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.

b) apparently VIRTIO_BLK works only when VIRTIO_PCI and thus PCI is
enabled in the kernel. Otherwise the vda* device is not visible and the
guest does not find its root filesystem.

Is this expected? If yes, is it possible to add the appropriate
dependency in the kernel configuration or amend the description
accordingly?

Thanks,
Bernhard

Re: Freeze with KVM_CLOCK, undocumented dependency VIRTIO_BLK -> VIRTIO_PCI

[Anthony Liguori]

Bernhard Schmidt wrote:
> Hi,
>
> apologies if those questions have already been answered, I did not find
> anything specific that should still be visible.
>
> I'm currently testing KVM (kvm-0.70 package from Debian unstable,
> rebuilt on Ubuntu Hardy) on a Athlon64 in i386 mode and found two small
> issues while trying to build a small kernel for my guest systems
> (2.6.26-rc6).
>
> a) when I enable KVM_CLOCK in the kernel configuration the guest system
> freezes after
>
> PCI: Found IRQ 11 for device 0000:00:04.0
>  vda: vda1 vda2
> TCP cubic registered
> NET: Registered protocol family 10
> NET: Registered protocol family 17
> Using IPI Shortcut mode
>
> when I disable KVM_CLOCK it mounts the filesystem and boots just fine
>
> Using IPI Shortcut mode
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.
>   

There are some outstanding patches for KVM_CLOCK that may fix this problem.

> b) apparently VIRTIO_BLK works only when VIRTIO_PCI and thus PCI is
> enabled in the kernel. Otherwise the vda* device is not visible and the
> guest does not find its root filesystem.
>
> Is this expected? If yes, is it possible to add the appropriate
> dependency in the kernel configuration or amend the description
> accordingly?
>   

VIRTIO_BLK doesn't depend on VIRTIO_PCI.  VIRTIO_PCI allows you use to 
virtio devices under KVM.

This is all documented FWIW in the Kconfig and in a number of places on 
the wiki.

Regards,

Anthony Liguori

> Thanks,
> Bernhard
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: Freeze with KVM_CLOCK, undocumented dependency VIRTIO_BLK -> VIRTIO_PCI

[Bernhard Schmidt]

Hi,

>> a) when I enable KVM_CLOCK in the kernel configuration the guest system
>> freezes after
>>
>> PCI: Found IRQ 11 for device 0000:00:04.0
>>  vda: vda1 vda2
>> TCP cubic registered
>> NET: Registered protocol family 10
>> NET: Registered protocol family 17
>> Using IPI Shortcut mode
> There are some outstanding patches for KVM_CLOCK that may fix this problem.

Any pointers? I'd love to test and confirm.

>> b) apparently VIRTIO_BLK works only when VIRTIO_PCI and thus PCI is
>> enabled in the kernel. Otherwise the vda* device is not visible and the
>> guest does not find its root filesystem.
>>
>> Is this expected? If yes, is it possible to add the appropriate
>> dependency in the kernel configuration or amend the description
>> accordingly?
> VIRTIO_BLK doesn't depend on VIRTIO_PCI.  VIRTIO_PCI allows you use to 
> virtio devices under KVM.

I don't quite understand. VIRTIO_BLK can be selected in the kernel 
without selecting VIRTIO_PCI, it does not generate any build error but 
the virtual blockdevice simply does appear. Does VIRTIO_BLK have any use 
without VIRTIO_PCI?

> This is all documented FWIW in the Kconfig and in a number of places on 
> the wiki.

Where exactly in Kconfig?

VIRTIO_BLK says nothing about VIRTIO_PCI or PCI, same for VIRTIO_NET. 
Yes, the VIRTIO_PCI Kconfig help says this "provides support for virtio 
based paravirtual device drivers over PCI". But this is far far away 
from the virtio drivers themselves, so one might not immediately notice 
that this is necessary. And if I disabled PCI completely (as a migrating 
Xen user who does not need PCI in domU at all) I won't even see the 
VIRTIO_PCI node, but still be able to select VIRTIO_BLK and _NET (which 
compile just fine but don't work, very confusing).

Bernhard

Re: Freeze with KVM_CLOCK, undocumented dependency VIRTIO_BLK -> VIRTIO_PCI

[Mark McLoughlin]

On Sat, 2008-06-21 at 21:41 -0500, Anthony Liguori wrote:
> Bernhard Schmidt wrote:

> > b) apparently VIRTIO_BLK works only when VIRTIO_PCI and thus PCI is
> > enabled in the kernel. Otherwise the vda* device is not visible and the
> > guest does not find its root filesystem.
> >
> > Is this expected? If yes, is it possible to add the appropriate
> > dependency in the kernel configuration or amend the description
> > accordingly?
> >   
> 
> VIRTIO_BLK doesn't depend on VIRTIO_PCI.  VIRTIO_PCI allows you use to 
> virtio devices under KVM.
> 
> This is all documented FWIW in the Kconfig and in a number of places on 
> the wiki.

I wonder would it be useful to default to building in (i.e. not as a
module) virtio_pci if building with e.g. KVM_GUEST?

There's two issues here:

  1) It's easy to forget about virtio_pci - if we used KVM_GUEST as a 
     general "this kernel may be run on KVM" config, then it would be a 
     good hint that virtio_pci should be built

  2) Although we currently build virtio_pci as a module in Fedora, it 
     leads to a pretty strange situation where e.g. mkinitrd and 
     anaconda need to explicitly include the virtio_pci module; I 
     don't think there's analogous situation where bus probing logic is 
     in a module rather than built into the kernel

Cheers,
Mark.

Re: Freeze with KVM_CLOCK, undocumented dependency VIRTIO_BLK -> VIRTIO_PCI

[Avi Kivity]

Mark McLoughlin wrote:
> I wonder would it be useful to default to building in (i.e. not as a
> module) virtio_pci if building with e.g. KVM_GUEST?
>
> There's two issues here:
>
>   1) It's easy to forget about virtio_pci - if we used KVM_GUEST as a 
>      general "this kernel may be run on KVM" config, then it would be a 
>      good hint that virtio_pci should be built
>
>   

Yeah.

>   2) Although we currently build virtio_pci as a module in Fedora, it 
>      leads to a pretty strange situation where e.g. mkinitrd and 
>      anaconda need to explicitly include the virtio_pci module; I 
>      don't think there's analogous situation where bus probing logic is 
>      in a module rather than built into the kernel
>
>   

Sounds like an mkinitrd bug.  When mkinitrd includes a module, it should 
also include all of its dependencies.

-- 
error compiling committee.c: too many arguments to function

Re: Freeze with KVM_CLOCK, undocumented dependency VIRTIO_BLK -> VIRTIO_PCI

[Mark McLoughlin]

On Thu, 2008-07-03 at 17:03 +0300, Avi Kivity wrote:
> Mark McLoughlin wrote:

> >   2) Although we currently build virtio_pci as a module in Fedora, it 
> >      leads to a pretty strange situation where e.g. mkinitrd and 
> >      anaconda need to explicitly include the virtio_pci module; I 
> >      don't think there's analogous situation where bus probing logic is 
> >      in a module rather than built into the kernel
> >
> >   
> 
> Sounds like an mkinitrd bug.  When mkinitrd includes a module, it should 
> also include all of its dependencies.

It does ... but nothing requires virtio_pci ...

Cheers,
Mark.

Re: Freeze with KVM_CLOCK, undocumented dependency VIRTIO_BLK -> VIRTIO_PCI

[Avi Kivity]

Mark McLoughlin wrote:
>
>>>   2) Although we currently build virtio_pci as a module in Fedora, it 
>>>      leads to a pretty strange situation where e.g. mkinitrd and 
>>>      anaconda need to explicitly include the virtio_pci module; I 
>>>      don't think there's analogous situation where bus probing logic is 
>>>      in a module rather than built into the kernel
>>>
>>>   
>>>       
>> Sounds like an mkinitrd bug.  When mkinitrd includes a module, it should 
>> also include all of its dependencies.
>>     
>
> It does ... but nothing requires virtio_pci ...
>
>   

Right, of course.  Virtio requires *some* virtio bus, not necessarily 
virtio-pci.

-- 
error compiling committee.c: too many arguments to function

Re: Freeze with KVM_CLOCK, undocumented dependency VIRTIO_BLK -> VIRTIO_PCI

[Christian Borntraeger]

Am Montag, 23. Juni 2008 schrieb Bernhard Schmidt:
> I don't quite understand. VIRTIO_BLK can be selected in the kernel 
> without selecting VIRTIO_PCI, it does not generate any build error but 
> the virtual blockdevice simply does appear. Does VIRTIO_BLK have any use 
> without VIRTIO_PCI?

Yes, it does.
virtio_pci is just one of currently 3 virtio transports.
drivers/lguest/lguest_devices.c (CONFIG_LGUEST_GUEST) and 
drivers/s390/kvm/kvm_virtio.c are other transports that make virtio_blk 
usable.

Christian