All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <levinsasha928@gmail.com>
To: Gabe Black <gabeblack@chromium.org>
Cc: kvm <kvm@vger.kernel.org>, Ronald Minnich <rminnich@google.com>
Subject: Re: Fix for bug that causes "KVM_GET_SUPPORTED_CPUID failed" errors.
Date: Tue, 24 Jan 2012 02:40:04 -0500	[thread overview]
Message-ID: <1327390804.32498.2.camel@lappy> (raw)
In-Reply-To: <CAPPXG1=v+-d91RWJ1jS7fpZrp9OTkHjowPRvCWXn2pz62vxtPw@mail.gmail.com>

The GET_SUPPORTED_CPUID bug has been fixed and shouldn't be happening
from v3.2 onwards.

Do you still see the issue in older versions?

On Mon, 2012-01-23 at 21:20 -0800, Gabe Black wrote:
> Sorry, forgot to add a subject.
> 
> Gabe
> 
> On Mon, Jan 23, 2012 at 9:18 PM, Gabe Black <gabeblack@google.com> wrote:
> > Hi, I think I've tracked down the bug that causes
> > "KVM_GET_SUPPORTED_CPUID failed: Argument list too long" errors when
> > using the kvm tool. Basically, this (possibly squished) code seems to
> > be to blame:
> >
> > case 0xd: {
> > int i;
> >
> > entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
> > for (i = 1; *nent < maxnent && i < 64; ++i) {
> > if (entry[i].eax == 0)
> > continue;
> > do_cpuid_1_ent(&entry[i], function, i);
> > entry[i].flags |=
> >      KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
> > ++*nent;
> > }
> > break;
> > }
> >
> > You can see there's a check whether entry[i].eax is 0, but it isn't
> > until the next line that entry[i] is actually filled in. That means
> > that whether or not an entry is filled in for the 0xd function is
> > essentially random, and that can lead to the loss of valid entries. It
> > also means that nent may be incremented too often, and since all 64
> > entries are iterated over, that can fill up the available storage and
> > cause that error.
> >
> > I tested my theory by commenting out the if (100% failure rate) and
> > moving it after do_cpuid_1_ent (100% success rate). Since this is a
> > non-deterministic failure that isn't really conclusive, but I'm fairly
> > confident my fix is correct. I don't know exactly what your procedure
> > is for submitting patches, but one is attached.
> >
> > Gabe
> --
> 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


-- 

Sasha.


  reply	other threads:[~2012-01-24  5:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-24  5:20 Fix for bug that causes "KVM_GET_SUPPORTED_CPUID failed" errors Gabe Black
2012-01-24  7:40 ` Sasha Levin [this message]
2012-01-24 21:53   ` Gabe Black

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1327390804.32498.2.camel@lappy \
    --to=levinsasha928@gmail.com \
    --cc=gabeblack@chromium.org \
    --cc=kvm@vger.kernel.org \
    --cc=rminnich@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.