From: Peter Xu <peterx@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Fam Zheng <fam@euphon.net>,
QEMU Block List <qemu-block@nongnu.org>,
Juan Quintela <quintela@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v2 0/4] apic: Fix migration breakage of >255 vcpus
Date: Wed, 23 Oct 2019 15:57:01 +0800 [thread overview]
Message-ID: <20191023075701.GA18443@xz-x1> (raw)
In-Reply-To: <20191019034153.GB9478@xz-x1>
On Sat, Oct 19, 2019 at 11:41:53AM +0800, Peter Xu wrote:
> On Wed, Oct 16, 2019 at 11:40:01AM -0300, Eduardo Habkost wrote:
> > On Wed, Oct 16, 2019 at 10:29:29AM +0800, Peter Xu wrote:
> > > v2:
> > > - use uint32_t rather than int64_t [Juan]
> > > - one more patch (patch 4) to check dup SaveStateEntry [Dave]
> > > - one more patch to define a macro (patch 1) to simplify patch 2
> > >
> > > Please review, thanks.
> >
> > I wonder how hard it is to write a simple test case to reproduce
> > the original bug. We can extend tests/migration-test.c or
> > tests/acceptance/migration.py. If using -device with explicit
> > apic-id, we probably don't even need to create >255 VCPUs.
>
> I can give it a shot next week. :)
When trying this, I probably noticed a block layer issue: q35 seems to
have problem on booting from a very small block device (like 512B,
which is the image size that currently used for migration-test.c).
For example, this cmdline can boot successfully into the test image:
$qemu -M pc -m 200m -accel kvm -nographic \
-drive file=$image,id=drive0,index=0,format=raw \
-device ide-hd,drive=drive0
While this cannot:
$qemu -M q35 -m 200m -accel kvm -nographic \
-drive file=$image,id=drive0,index=0,format=raw \
-device ide-hd,drive=drive0
With error (BIOS debug messages on):
Booting from Hard Disk..invalid basic_access:143:
a=00000201 b=00000000 c=00000001 d=00000080 ds=0000 es=07c0 ss=d980
si=00000000 di=00000000 bp=00000000 sp=0000fd8e cs=f000 ip=cb81 f=0202
invalid basic_access:144:
a=00000201 b=00000000 c=00000001 d=00000080 ds=0000 es=07c0 ss=d980
si=00000000 di=00000000 bp=00000000 sp=0000fd8e cs=f000 ip=cb81 f=0202
.
Boot failed: could not read the boot disenter handle_18:
NULL
k
This corresponds to this SeaBIOS check error:
static void noinline
basic_access(struct bregs *regs, struct drive_s *drive_fl, u16 command)
{
...
// sanity check on cyl heads, sec
if (cylinder >= nlc || head >= nlh || sector > nls) {
warn_invalid(regs);
disk_ret(regs, DISK_RET_EPARAM);
return;
}
...
}
And... below cmdline will work even for q35 (as suggested by Fam when
we talked offline):
$qemu -M q35 -m 200m -accel kvm -nographic \
-drive file=$image,id=drive0,index=0,format=raw \
-device ide-hd,drive=drive0,secs=1,cyls=1,heads=1
I think for migration test we can workaround like above, but I'm also
curious whether this is a real bug somewhere because I don't see a
reason for q35 to refuse to boot on a one-sector image.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2019-10-23 7:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 2:29 [PATCH v2 0/4] apic: Fix migration breakage of >255 vcpus Peter Xu
2019-10-16 2:29 ` [PATCH v2 1/4] migration: Define VMSTATE_INSTANCE_ID_ANY Peter Xu
2019-10-16 8:43 ` Juan Quintela
2019-10-16 2:29 ` [PATCH v2 2/4] migration: Change SaveStateEntry.instance_id into uint32_t Peter Xu
2019-10-16 8:43 ` Juan Quintela
2019-10-16 2:29 ` [PATCH v2 3/4] apic: Use 32bit APIC ID for migration instance ID Peter Xu
2019-10-16 2:42 ` Eduardo Habkost
2019-10-16 8:44 ` Juan Quintela
2019-10-16 2:29 ` [PATCH v2 4/4] migration: Check in savevm_state_handler_insert for dups Peter Xu
2019-10-16 9:14 ` Dr. David Alan Gilbert
2019-10-16 10:08 ` Juan Quintela
2020-01-10 16:35 ` Juan Quintela
2019-10-16 14:40 ` [PATCH v2 0/4] apic: Fix migration breakage of >255 vcpus Eduardo Habkost
2019-10-19 3:41 ` Peter Xu
2019-10-23 7:57 ` Peter Xu [this message]
2019-10-23 8:17 ` Kevin Wolf
2019-10-24 17:49 ` John Snow
2019-10-25 0:00 ` Peter Xu
2019-10-23 10:39 ` Peter Xu
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=20191023075701.GA18443@xz-x1 \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=fam@euphon.net \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).