From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: virtio breakage with 2.6.25 guest kernel Date: Thu, 15 Jan 2009 12:47:53 +1030 Message-ID: <200901151247.53979.rusty@rustcorp.com.au> References: <496C9813.7000609@suse.de> <2D739E97-509B-4523-B04B-B18364C152EB@suse.de> <1231924978.4944.76.camel@localhost.localdomain> Reply-To: qemu-devel@nongnu.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary-00=_RzpbJ8EaV8Sv0tL" Content-Transfer-Encoding: 7bit Cc: "qemu-devel@nongnu.org" , Alexander Graf , kvm-devel To: Mark McLoughlin Return-path: In-Reply-To: <1231924978.4944.76.camel@localhost.localdomain> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org --Boundary-00=_RzpbJ8EaV8Sv0tL Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wednesday 14 January 2009 19:52:58 Mark McLoughlin wrote: > On Tue, 2009-01-13 at 22:05 +0100, Alexander Graf wrote: > > > On 13.01.2009, at 21:14, Anthony Liguori wrote: > > > > > Alexander Graf wrote: > > >> Hi, > > >> > > >> while I don't fully understand the problem, here's what I > > >> experience so far: > > >> > > >> When using an openSUSE 11.0 kernel (2.6.25) in the guest, virtio on > > >> tap > > >> breaks with current KVM git, while it used to work before (haven't > > >> bisected, definitely worked in kvm-78, but is probably due to > > >> Anthony's > > >> rewrite). It shows the following message (comes from qemu): > > >> > > > > > > There were a couple of old-guest-breaking regressions. I think > > > we've fixed all of them but there could be more. Are you using the > > > latest kvm-userspace? > > See: > > http://lists.gnu.org/archive/html/qemu-devel/2009-01/msg00574.html > > > This one is definitely due to the broken guest kernel. I applied the > > patch mark mentioned to ours and things started working. > > > > So the only way I can think of to 'fix' it is by detecting broken > > guests. We could supply a host mask of 0xffffffff and see if tge guest > > feature mask is tge same. If so, feature masking is probably broken. > > Nice idea, but no way of making the guest through feature detection > negotiation, I don't think. Just add a feature "VIRTIO_F_LIES_ABOUT_FEATURES"? No guest should ever set this. But I'm not sure it's worth the pain... Rusty. --Boundary-00=_RzpbJ8EaV8Sv0tL Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit

On Wednesday 14 January 2009 19:52:58 Mark McLoughlin wrote:

> On Tue, 2009-01-13 at 22:05 +0100, Alexander Graf wrote:

>

> > On 13.01.2009, at 21:14, Anthony Liguori <anthony@codemonkey.ws> wrote:

> >

> > > Alexander Graf wrote:

> > >> Hi,

> > >>

> > >> while I don't fully understand the problem, here's what I

> > >> experience so far:

> > >>

> > >> When using an openSUSE 11.0 kernel (2.6.25) in the guest, virtio on

> > >> tap

> > >> breaks with current KVM git, while it used to work before (haven't

> > >> bisected, definitely worked in kvm-78, but is probably due to

> > >> Anthony's

> > >> rewrite). It shows the following message (comes from qemu):

> > >>

> > >

> > > There were a couple of old-guest-breaking regressions. I think

> > > we've fixed all of them but there could be more. Are you using the

> > > latest kvm-userspace?

>

> See:

>

> http://lists.gnu.org/archive/html/qemu-devel/2009-01/msg00574.html

>

> > This one is definitely due to the broken guest kernel. I applied the

> > patch mark mentioned to ours and things started working.

> >

> > So the only way I can think of to 'fix' it is by detecting broken

> > guests. We could supply a host mask of 0xffffffff and see if tge guest

> > feature mask is tge same. If so, feature masking is probably broken.

>

> Nice idea, but no way of making the guest through feature detection

> negotiation, I don't think.

Just add a feature "VIRTIO_F_LIES_ABOUT_FEATURES"? No guest should ever set this.

But I'm not sure it's worth the pain...

Rusty.

--Boundary-00=_RzpbJ8EaV8Sv0tL--