[Qemu-devel] [Bug 1769189] Re: Issue with qemu 2.12.0 + SATA

2018-06-14 Thread Robert Hu 
Hi, Where can I find the fix patch at present?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189

Title:
  Issue with qemu 2.12.0 + SATA

Status in QEMU:
  Fix Committed

Bug description:
  [EDIT: I first thought that OVMF was the issue, but it turns out to be
  SATA]

  I had a Windows 10 VM running perfectly fine with a SATA drive, since
  I upgraded to qemu 2.12, the guests hangs for a couple of minutes,
  works for a few seconds, and hangs again, etc. By "hang" I mean it
  doesn't freeze, but it looks like it's waiting on IO or something, I
  can move the mouse but everything needing disk access is unresponsive.

  What doesn't work: qemu 2.12 with SATA
  What works: using VirIO-SCSI with qemu 2.12 or downgrading qemu to 2.11.1 and 
keep using SATA.

  Platform is arch linux 4.16.7 on skylake and Haswell, I have attached
  the vm xml file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions

[Qemu-devel] [Bug 1686350] [NEW] [KVM] The qemu ‘-cpu’ option not have skylake server cpu model

2017-04-26 Thread Robert Hu 
Public bug reported:

Environment:
---
KVM commit/branch: bd17117b/next
Qemu commit/branch: cd1ea508/master
Host OS: RHEL7.3 ia32e
Host Kernel:4.11.0-rc3
Bug detailed description:
--
In latest qemu commit the qemu still not have skylake server cpu model
Reproduce steps:
-
[root@skl-2s2 ~]# qemu-system-x86_64 -cpu help
Available CPUs:
x86 486
x86 Broadwell-noTSX Intel Core Processor (Broadwell, no TSX)
x86 Broadwell Intel Core Processor (Broadwell)
x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2)
x86 Haswell-noTSX Intel Core Processor (Haswell, no TSX)
x86 Haswell Intel Core Processor (Haswell)
x86 IvyBridge Intel Xeon E3-12xx v2 (Ivy Bridge)
x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7)
x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron)
x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron)
x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron)
x86 Opteron_G4 AMD Opteron 62xx class CPU
x86 Opteron_G5 AMD Opteron 63xx class CPU
x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2)
x86 SandyBridge Intel Xeon E312xx (Sandy Bridge)
x86 Skylake-Client Intel Core Processor (Skylake)
x86 Westmere Westmere E56xx/L56xx/X56xx (Nehalem-C)
x86 athlon QEMU Virtual CPU version 2.5+
x86 core2duo Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
x86 coreduo Genuine Intel(R) CPU T2600 @ 2.16GHz
x86 kvm32 Common 32-bit KVM processor
x86 kvm64 Common KVM processor
x86 n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz
x86 pentium
x86 pentium2
x86 pentium3
x86 phenom AMD Phenom(tm) 9550 Quad-Core Processor
x86 qemu32 QEMU Virtual CPU version 2.5+
x86 qemu64 QEMU Virtual CPU version 2.5+
x86 base base CPU model type with no features enabled
x86 host KVM processor with all supported host features (only available in KVM 
mode)
x86 max Enables all features supported by the accelerator in the current host

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1686350

Title:
  [KVM] The qemu ‘-cpu’ option not have skylake server cpu model

Status in QEMU:
  New

Bug description:
  Environment:
  ---
  KVM commit/branch: bd17117b/next
  Qemu commit/branch: cd1ea508/master
  Host OS: RHEL7.3 ia32e
  Host Kernel:4.11.0-rc3
  Bug detailed description:
  --
  In latest qemu commit the qemu still not have skylake server cpu model
  Reproduce steps:
  -
  [root@skl-2s2 ~]# qemu-system-x86_64 -cpu help
  Available CPUs:
  x86 486
  x86 Broadwell-noTSX Intel Core Processor (Broadwell, no TSX)
  x86 Broadwell Intel Core Processor (Broadwell)
  x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2)
  x86 Haswell-noTSX Intel Core Processor (Haswell, no TSX)
  x86 Haswell Intel Core Processor (Haswell)
  x86 IvyBridge Intel Xeon E3-12xx v2 (Ivy Bridge)
  x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7)
  x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron)
  x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron)
  x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron)
  x86 Opteron_G4 AMD Opteron 62xx class CPU
  x86 Opteron_G5 AMD Opteron 63xx class CPU
  x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2)
  x86 SandyBridge Intel Xeon E312xx (Sandy Bridge)
  x86 Skylake-Client Intel Core Processor (Skylake)
  x86 Westmere Westmere E56xx/L56xx/X56xx (Nehalem-C)
  x86 athlon QEMU Virtual CPU version 2.5+
  x86 core2duo Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
  x86 coreduo Genuine Intel(R) CPU T2600 @ 2.16GHz
  x86 kvm32 Common 32-bit KVM processor
  x86 kvm64 Common KVM processor
  x86 n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz
  x86 pentium
  x86 pentium2
  x86 pentium3
  x86 phenom AMD Phenom(tm) 9550 Quad-Core Processor
  x86 qemu32 QEMU Virtual CPU version 2.5+
  x86 qemu64 QEMU Virtual CPU version 2.5+
  x86 base base CPU model type with no features enabled
  x86 host KVM processor with all supported host features (only available in 
KVM mode)
  x86 max Enables all features supported by the accelerator in the current host

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1686350/+subscriptions

[Qemu-devel] [Bug 1656234] [NEW] Qemu core dumped if using virtio-net

2017-01-13 Thread Robert Hu 
Public bug reported:

System Environment
===
Qemu commit/branch: e92fbc75
Host OS: RHEL7.2 ia32e
Host Kernel: 4.9.0
Guest OS: RHEL7.2 ia32e
Guest Kernel: 4.9.0

Bug detailed description
===
While create a kvm guest using virtio-net, the qemu will core dump with showing 
"Aborted (core dumped)".
Reproduce Steps
==
create a guest:
qemu-system-x86_64 -enable-kvm -m 4096 -smp 4 -device 
virtio-net-pci,netdev=nic0,mac=00:16:3e:49:be:24 -netdev 
tap,id=nic0,script=/etc/kvm/qemu-ifup -drive 
file=/ia32e_rhel7u2_kvm.qcow2,if=none,id=virtio-disk0 -device 
virtio-blk-pci,drive=virtio-disk0 -serial file:serial.log

Current Result:
==

qemu-system-x86_64: 
/workspace/ia32e/nightly/kvm-next-20170105-ef85b6-e92fbc/kvm/qemu/hw/virtio/virtio.c:214:
 virtio_queue_set_notification: Assertion `vq->notification_disabled > 0' 
failed.
Aborted (core dumped)

add info

[root@hsw-ep2 Desktop]# dmesg |grep -v virbr0 |tail -n 10
[ 1760.265000] device tap0 left promiscuous mode
[ 1879.148642] device tap0 entered promiscuous mode
[ 1885.213702] kvm [14186]: vcpu0, guest rIP: 0x81066784 disabled 
perfctr wrmsr: 0xc2 data 0x
[ 1912.258783] device tap0 left promiscuous mode
[ 1995.972267] device tap0 entered promiscuous mode
[ 2001.990207] kvm [14335]: vcpu0, guest rIP: 0x81066784 disabled 
perfctr wrmsr: 0xc2 data 0x
[ 2024.703072] device tap0 left promiscuous mode
[ 2145.374239] device tap0 entered promiscuous mode
[ 2151.409948] kvm [14541]: vcpu0, guest rIP: 0x81066784 disabled 
perfctr wrmsr: 0xc2 data 0x
[ 2178.281446] device tap0 left promiscuous mode

** Affects: qemu
 Importance: Undecided
 Status: New

** Attachment added: "guest serial log"
   https://bugs.launchpad.net/bugs/1656234/+attachment/4803773/+files/serial.log

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1656234

Title:
  Qemu core dumped if using virtio-net

Status in QEMU:
  New

Bug description:
  System Environment
  ===
  Qemu commit/branch: e92fbc75
  Host OS: RHEL7.2 ia32e
  Host Kernel: 4.9.0
  Guest OS: RHEL7.2 ia32e
  Guest Kernel: 4.9.0

  Bug detailed description
  ===
  While create a kvm guest using virtio-net, the qemu will core dump with 
showing "Aborted (core dumped)".
  Reproduce Steps
  ==
  create a guest:
  qemu-system-x86_64 -enable-kvm -m 4096 -smp 4 -device 
virtio-net-pci,netdev=nic0,mac=00:16:3e:49:be:24 -netdev 
tap,id=nic0,script=/etc/kvm/qemu-ifup -drive 
file=/ia32e_rhel7u2_kvm.qcow2,if=none,id=virtio-disk0 -device 
virtio-blk-pci,drive=virtio-disk0 -serial file:serial.log

  Current Result:
  ==

  qemu-system-x86_64: 
/workspace/ia32e/nightly/kvm-next-20170105-ef85b6-e92fbc/kvm/qemu/hw/virtio/virtio.c:214:
 virtio_queue_set_notification: Assertion `vq->notification_disabled > 0' 
failed.
  Aborted (core dumped)

  add info
  
  [root@hsw-ep2 Desktop]# dmesg |grep -v virbr0 |tail -n 10
  [ 1760.265000] device tap0 left promiscuous mode
  [ 1879.148642] device tap0 entered promiscuous mode
  [ 1885.213702] kvm [14186]: vcpu0, guest rIP: 0x81066784 disabled 
perfctr wrmsr: 0xc2 data 0x
  [ 1912.258783] device tap0 left promiscuous mode
  [ 1995.972267] device tap0 entered promiscuous mode
  [ 2001.990207] kvm [14335]: vcpu0, guest rIP: 0x81066784 disabled 
perfctr wrmsr: 0xc2 data 0x
  [ 2024.703072] device tap0 left promiscuous mode
  [ 2145.374239] device tap0 entered promiscuous mode
  [ 2151.409948] kvm [14541]: vcpu0, guest rIP: 0x81066784 disabled 
perfctr wrmsr: 0xc2 data 0x
  [ 2178.281446] device tap0 left promiscuous mode

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1656234/+subscriptions

Re: [Qemu-devel] [PATCH 2/2] Explicitly print out default vnc option in use

2016-06-18 Thread Robert Hu 
On Wed, 2016-06-08 at 16:22 +0200, Markus Armbruster wrote:
> Robert Hu <robert...@vmm.sh.intel.com> writes:
> 
> > On Mon, 2016-06-06 at 09:28 +0200, Markus Armbruster wrote:
> >> Robert Hu <robert...@vmm.sh.intel.com> writes:
> >> 
> >> > On Tue, 2016-05-31 at 13:17 +0200, Markus Armbruster wrote:
> >> >> Robert Hu <robert...@vmm.sh.intel.com> writes:
> >> >> 
> >> >> > On Tue, 2016-05-31 at 09:51 +0200, Markus Armbruster wrote:
> > [trim...]
> >> > I don't see a './configure' option related to this '-vnc to' param. Is
> >> > there any?
> >> > '--help', you mean 'qemu-system_x86-64 --help'? or './configure --help'?
> > [seems repeated contents, trim...]
> >> > I don't see a './configure' option related to this '-vnc to' param. Is
> >> > there any?
> >> > '--help', you mean 'qemu-system_x86-64 --help'? or './configure --help'?
> >> 
> >> The former.
> >> 
> >> The modern way to select a display is -display.  The older -nographic,
> >> -curses, -sdl are retained for backward compatibility.
> >> 
> >> Relevant parts of -help:
> >> 
> >> Display options:
> >> -display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]
> >> [,window_close=on|off]|curses|none|
> >> gtk[,grab_on_hover=on|off]|
> >> vnc=[,]
> >> select display type
> >> -nographic  disable graphical output and redirect serial I/Os to 
> >> console
> >> -curses use a curses/ncurses interface instead of SDL
> >> [...]
> >> -sdlenable SDL
> >> [...]
> >> -vnc displaystart a VNC server on display
> >> 
> >> Issues:
> >> 
> >> * Help for -display is broken: the mutually exclusive option arguments
> >>   are concatenated.  -display curses and -display none are undocumented.
> >>   It should look more like this:
> >> 
> >> -display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]
> >> [,window_close=on|off]|curses|none|
> >> -display gtk[,grab_on_hover=on|off]|
> >> -display vnc=[,]
> >> -display curses
> >> -display none
> >> select display type
> >> 
> >> * -display sdl,gl=on|off and -display gtk,gl=on|off are undocumented
> >>(missed in commit 0b71a5d5c and 97edf3b).
> >> 
> >> * There is no help on the  in -display vnc=.
> >> 
> >> * There is no help on the default.  main() picks the default depending
> >>   on configure options:
> >> 
> >> #if defined(CONFIG_GTK)
> >> display_type = DT_GTK;
> >> #elif defined(CONFIG_SDL)
> >> display_type = DT_SDL;
> >> #elif defined(CONFIG_COCOA)
> >> display_type = DT_COCOA;
> >> #elif defined(CONFIG_VNC)
> >> vnc_parse("localhost:0,to=99,id=default", _abort);
> >> show_vnc_port = 1;
> >> #else
> >> display_type = DT_NONE;
> >> #endif
> >> 
> >>   Help should show the default this binary will pick.  This is what I
> >>   meant by "Ideally, --help output would show the defaults for this
> >>   build's configuration."
> >> 
> >> * Help should explain syntacic sugar:
> >>   -curses is sugar for -display curses
> >>   -sdl is sugar for -display sdl
> >>   -vnc display is sugar for -display vnc=display
> >> 
> >>   -nographic is also sugar, but too complicated to explain; I'd leave it
> >>   as is.
> >> 
> >> Non-issue
> >> 
> >> * Help shows options even when they're not compiled in.  That's okay,
> >>   because trying to use them fails with an "FOO support is disabled"
> >>   error message.
> >> 
> >> >> If we decide users need more information than the current "VNC server
> >> >> running on" line, perhaps it should be included right in that line.
> >> 
> >> This would complement, but not replace better -help ouput.
> >> 
> >> If you would like to work on these issues, let us know.
> >
> > OK, if not in a hurry and assuming this is not a huge amount of work.
> > I also need to look into the build arch so that completely understand
> > your 'the default this binary will pick', till now I don't.
> >
> > Another concern is that I'm not a native English speaker, so those
> > description words may not be that apt and concise.
> 
> Imperfect English can be addressed in review.  Can be inefficient when
> most of the work is English rather than code.  But if you want to try
> anyway, go right ahead regardless.

Hi Markus,

After did some part-time investigation, I'd like to confirm with you:
this change you required seems also just qemu-options.hx involved, am I
right?
If so, I'd like to do that.

> 
> [...]

Re: [Qemu-devel] [PATCH 2/2] Explicitly print out default vnc option in use

2016-06-06 Thread Robert Hu 
On Tue, 2016-06-07 at 08:28 +0800, Robert Hu wrote:
> On Mon, 2016-06-06 at 09:28 +0200, Markus Armbruster wrote:
> > Robert Hu <robert...@vmm.sh.intel.com> writes:
> > 
> > > On Tue, 2016-05-31 at 13:17 +0200, Markus Armbruster wrote:
> > >> Robert Hu <robert...@vmm.sh.intel.com> writes:
> > >> 
> > >> > On Tue, 2016-05-31 at 09:51 +0200, Markus Armbruster wrote:
> [trim...]
> > > I don't see a './configure' option related to this '-vnc to' param. Is
> > > there any?
> > > '--help', you mean 'qemu-system_x86-64 --help'? or './configure --help'?
> [seems repeated contents, trim...]
> > > I don't see a './configure' option related to this '-vnc to' param. Is
> > > there any?
> > > '--help', you mean 'qemu-system_x86-64 --help'? or './configure --help'?
> > 
> > The former.
> > 
> > The modern way to select a display is -display.  The older -nographic,
> > -curses, -sdl are retained for backward compatibility.
> > 
> > Relevant parts of -help:
> > 
> > Display options:
> > -display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]
> > [,window_close=on|off]|curses|none|
> > gtk[,grab_on_hover=on|off]|
> > vnc=[,]
> > select display type
> > -nographic  disable graphical output and redirect serial I/Os to 
> > console
> > -curses use a curses/ncurses interface instead of SDL
> > [...]
> > -sdlenable SDL
> > [...]
> > -vnc displaystart a VNC server on display
> > 
> > Issues:
> > 
> > * Help for -display is broken: the mutually exclusive option arguments
> >   are concatenated.  -display curses and -display none are undocumented.
> >   It should look more like this:
> > 
> > -display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]
> > [,window_close=on|off]|curses|none|
> > -display gtk[,grab_on_hover=on|off]|
> > -display vnc=[,]
> > -display curses
> > -display none
> > select display type
> > 
> > * -display sdl,gl=on|off and -display gtk,gl=on|off are undocumented
> >(missed in commit 0b71a5d5c and 97edf3b).
> > 
> > * There is no help on the  in -display vnc=.
> > 
> > * There is no help on the default.  main() picks the default depending
> >   on configure options:
> > 
> > #if defined(CONFIG_GTK)
> > display_type = DT_GTK;
> > #elif defined(CONFIG_SDL)
> > display_type = DT_SDL;
> > #elif defined(CONFIG_COCOA)
> > display_type = DT_COCOA;
> > #elif defined(CONFIG_VNC)
> > vnc_parse("localhost:0,to=99,id=default", _abort);
> > show_vnc_port = 1;
> > #else
> > display_type = DT_NONE;
> > #endif
> > 
> >   Help should show the default this binary will pick.  This is what I
> >   meant by "Ideally, --help output would show the defaults for this
> >   build's configuration."
> > 
> > * Help should explain syntacic sugar:
> >   -curses is sugar for -display curses
> >   -sdl is sugar for -display sdl
> >   -vnc display is sugar for -display vnc=display
> > 
> >   -nographic is also sugar, but too complicated to explain; I'd leave it
> >   as is.
> > 
> > Non-issue
> > 
> > * Help shows options even when they're not compiled in.  That's okay,
> >   because trying to use them fails with an "FOO support is disabled"
> >   error message.
> > 
> > >> If we decide users need more information than the current "VNC server
> > >> running on" line, perhaps it should be included right in that line.
> > 
> > This would complement, but not replace better -help ouput.
> > 
> > If you would like to work on these issues, let us know.
> 
> OK, if not in a hurry and assuming this is not a huge amount of work.
> I also need to look into the build arch so that completely understand
> your 'the default this binary will pick', till now I don't.
> 
> Another concern is that I'm not a native English speaker, so those
> description words may not be that apt and concise.
> 
> Meanwhile, this is another work extended from the original patch. How
> about accept the patch 1 first? as you and Paolo both think it is OK.
> Ought I rework a version 2 of single patch 1? or not necessary?
Oh, I see Paolo already get it in. Thanks!
> 
>

Re: [Qemu-devel] [PATCH 2/2] Explicitly print out default vnc option in use

2016-06-06 Thread Robert Hu 
On Mon, 2016-06-06 at 09:28 +0200, Markus Armbruster wrote:
> Robert Hu <robert...@vmm.sh.intel.com> writes:
> 
> > On Tue, 2016-05-31 at 13:17 +0200, Markus Armbruster wrote:
> >> Robert Hu <robert...@vmm.sh.intel.com> writes:
> >> 
> >> > On Tue, 2016-05-31 at 09:51 +0200, Markus Armbruster wrote:
[trim...]
> > I don't see a './configure' option related to this '-vnc to' param. Is
> > there any?
> > '--help', you mean 'qemu-system_x86-64 --help'? or './configure --help'?
[seems repeated contents, trim...]
> > I don't see a './configure' option related to this '-vnc to' param. Is
> > there any?
> > '--help', you mean 'qemu-system_x86-64 --help'? or './configure --help'?
> 
> The former.
> 
> The modern way to select a display is -display.  The older -nographic,
> -curses, -sdl are retained for backward compatibility.
> 
> Relevant parts of -help:
> 
> Display options:
> -display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]
> [,window_close=on|off]|curses|none|
> gtk[,grab_on_hover=on|off]|
> vnc=[,]
> select display type
> -nographic  disable graphical output and redirect serial I/Os to 
> console
> -curses use a curses/ncurses interface instead of SDL
> [...]
> -sdlenable SDL
> [...]
> -vnc displaystart a VNC server on display
> 
> Issues:
> 
> * Help for -display is broken: the mutually exclusive option arguments
>   are concatenated.  -display curses and -display none are undocumented.
>   It should look more like this:
> 
> -display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]
> [,window_close=on|off]|curses|none|
> -display gtk[,grab_on_hover=on|off]|
> -display vnc=[,]
> -display curses
> -display none
> select display type
> 
> * -display sdl,gl=on|off and -display gtk,gl=on|off are undocumented
>(missed in commit 0b71a5d5c and 97edf3b).
> 
> * There is no help on the  in -display vnc=.
> 
> * There is no help on the default.  main() picks the default depending
>   on configure options:
> 
> #if defined(CONFIG_GTK)
> display_type = DT_GTK;
> #elif defined(CONFIG_SDL)
> display_type = DT_SDL;
> #elif defined(CONFIG_COCOA)
> display_type = DT_COCOA;
> #elif defined(CONFIG_VNC)
> vnc_parse("localhost:0,to=99,id=default", _abort);
> show_vnc_port = 1;
> #else
> display_type = DT_NONE;
> #endif
> 
>   Help should show the default this binary will pick.  This is what I
>   meant by "Ideally, --help output would show the defaults for this
>   build's configuration."
> 
> * Help should explain syntacic sugar:
>   -curses is sugar for -display curses
>   -sdl is sugar for -display sdl
>   -vnc display is sugar for -display vnc=display
> 
>   -nographic is also sugar, but too complicated to explain; I'd leave it
>   as is.
> 
> Non-issue
> 
> * Help shows options even when they're not compiled in.  That's okay,
>   because trying to use them fails with an "FOO support is disabled"
>   error message.
> 
> >> If we decide users need more information than the current "VNC server
> >> running on" line, perhaps it should be included right in that line.
> 
> This would complement, but not replace better -help ouput.
> 
> If you would like to work on these issues, let us know.

OK, if not in a hurry and assuming this is not a huge amount of work.
I also need to look into the build arch so that completely understand
your 'the default this binary will pick', till now I don't.

Another concern is that I'm not a native English speaker, so those
description words may not be that apt and concise.

Meanwhile, this is another work extended from the original patch. How
about accept the patch 1 first? as you and Paolo both think it is OK.
Ought I rework a version 2 of single patch 1? or not necessary?

Re: [Qemu-devel] [PATCH 0/2] Reveal 'to' parameter of 'vnc' option to user

2016-06-05 Thread Robert Hu 
On Tue, 2016-05-31 at 14:59 +0200, Paolo Bonzini wrote:
> 
> On 31/05/2016 09:03, Robert Ho wrote:
> > I find that '-vnc' option actually has a parameter 'to', implicitly;
> > while actually is there and can be used but not be public.
> > Don't know why but this may probably confuse user, especially when used in
> > some default situation implicitly. 
> > 
> > So shall I?
> > 1.  Add its description in QEMU manual info
> > 2.  Expilicitly print out when it's used with non-default value
> 
> I think patch 1 is okay.

Thanks Paolo. Sorry for late reply, since I just part-time work on this.

> 
> For patch 2, I am not sure I see the point of printing the VNC options;
> the VNC port is printed immediately after.

I agree it is not significantly meaningful to print out the options. I
just disliked the implicitly be-on-behalf-chose a value without
notification; especially we don't know there is a 'to' option. So when I
did the density test of huge quantity of guests, always failed on 99th,
made me quizzical. :(
In most ordinary cases, the final 'VNC server running on ...' printf is
sufficient.
Now my that emotion gradually die out, I agree abandon patch 2. :)

> 
> However, I think it is useful to print the VNC port whenever the user
> specifies "-vnc to=XX".  Perhaps you could move show_vnc_port (the
> variable, the assignments and the "if (show_vnc_port)") from vl.c to
> vnc_display_open?

And 2nd reason I abandon patch 2: I grepped in vnc.c, no bare 'printf'.
Any nice wrapper for such info purpose? I don't want to be first 'bad
guy' to break the elegant code. ;)

So do I need to send out v2 patch? which simply contains single patch 1.

> 
> Thanks,
> 
> Paolo

Re: [Qemu-devel] [PATCH 2/2] Explicitly print out default vnc option in use

2016-06-05 Thread Robert Hu 
On Tue, 2016-05-31 at 13:17 +0200, Markus Armbruster wrote:
> Robert Hu <robert...@vmm.sh.intel.com> writes:
> 
> > On Tue, 2016-05-31 at 09:51 +0200, Markus Armbruster wrote:
> >> Robert Ho <robert...@intel.com> writes:
> >> 
> >> > If no display option defined in QEMU command line, and SDL is not
> >> > available, then it by default uses '-vnc localhost:0,to=99,id=default'.
> >> > This patch simply print out the default option parameters out, so that
> >> > user is aware of that.
> >> >
> >> > Signed-off-by: Robert Ho <robert...@intel.com>
> >> > ---
> >> >  vl.c | 5 -
> >> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/vl.c b/vl.c
> >> > index 18d1423..8617a68 100644
> >> > --- a/vl.c
> >> > +++ b/vl.c
> >> > @@ -4213,7 +4213,10 @@ int main(int argc, char **argv, char **envp)
> >> >  #elif defined(CONFIG_COCOA)
> >> >  display_type = DT_COCOA;
> >> >  #elif defined(CONFIG_VNC)
> >> > -vnc_parse("localhost:0,to=99,id=default", _abort);
> >> > +#define DEFAULT_VNC_DISPLAY_OPTION  
> >> > "localhost:0,to=99,id=default"
> >> 
> >> Preprocessor directives shouldn't be indented.
> >> 
> >> Also tab damage.  Please use scripts/checkpatch.pl to check your patches.
> >
> > Thanks Markus for your review.
> > Firstly apologize if you received multiple copies of this patch. I'm
> > still struggling with my egress SMTP setting. I've no idea how many
> > copies you received:( but glad now see your reply.
> >
> > Yes, sorry about haven't checked the patch with the auxiliary scripts. I
> > didn't know that. Thanks for pointing out.
> > I'm new here, will learn these upstream convention ASAP.
> 
> No problem.  All we expect from new contributors is making an effort to
> get their patches right.  Actually getting them 100% right from the
> start isn't really in the cards :)

Thank You!
Sorry for late following up; for I just part-time do this. I'm too busy
on work these days.

> 
> >> > +vnc_parse(DEFAULT_VNC_DISPLAY_OPTION, _abort);
> >> > +printf("No display option defined, using '-vnc %s' by 
> >> > default   \
> >> > +\n", DEFAULT_VNC_DISPLAY_OPTION);
> >> >  show_vnc_port = 1;
> >> >  #else
> >> >  display_type = DT_NONE;
> >> 
> >> I don't like this.  Programs should be quiet unless they got something
> >> important to say.  Can't see why this particular default is more
> >> important than all the other defaults we don't print.
> >> 
> >> The default could be documented in output of --help.
> >
> > Actually my thought was this is not using the default value and
> > implicitly. The default of 'to' is 0, while in this case (when no
> > display option defined and SDL not configured in), it implicitly uses
> > non-default value '99'. Therefore I thought it shall be explicitly print
> > out so that user would be aware of what was chosen on behalf of him;
> > like the final print of 'VNC server running on '::1;5900''. 
> 
> The default depends on configuration options.  Ideally, --help output
> would show the defaults for this build's configuration.

I don't see a './configure' option related to this '-vnc to' param. Is
there any?
'--help', you mean 'qemu-system_x86-64 --help'? or './configure --help'?
> 
> If we decide users need more information than the current "VNC server
> running on" line, perhaps it should be included right in that line.

Re: [Qemu-devel] [PATCH 2/2] Explicitly print out default vnc option in use

2016-05-31 Thread Robert Hu 
On Tue, 2016-05-31 at 09:51 +0200, Markus Armbruster wrote:
> Robert Ho  writes:
> 
> > If no display option defined in QEMU command line, and SDL is not
> > available, then it by default uses '-vnc localhost:0,to=99,id=default'.
> > This patch simply print out the default option parameters out, so that
> > user is aware of that.
> >
> > Signed-off-by: Robert Ho 
> > ---
> >  vl.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/vl.c b/vl.c
> > index 18d1423..8617a68 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -4213,7 +4213,10 @@ int main(int argc, char **argv, char **envp)
> >  #elif defined(CONFIG_COCOA)
> >  display_type = DT_COCOA;
> >  #elif defined(CONFIG_VNC)
> > -vnc_parse("localhost:0,to=99,id=default", _abort);
> > +   #define DEFAULT_VNC_DISPLAY_OPTION  
> > "localhost:0,to=99,id=default"
> 
> Preprocessor directives shouldn't be indented.
> 
> Also tab damage.  Please use scripts/checkpatch.pl to check your patches.

Thanks Markus for your review.
Firstly apologize if you received multiple copies of this patch. I'm
still struggling with my egress SMTP setting. I've no idea how many
copies you received:( but glad now see your reply.

Yes, sorry about haven't checked the patch with the auxiliary scripts. I
didn't know that. Thanks for pointing out.
I'm new here, will learn these upstream convention ASAP.
> 
> > +vnc_parse(DEFAULT_VNC_DISPLAY_OPTION, _abort);
> > +   printf("No display option defined, using '-vnc %s' by default   
> > \
> > +\n", DEFAULT_VNC_DISPLAY_OPTION);
> >  show_vnc_port = 1;
> >  #else
> >  display_type = DT_NONE;
> 
> I don't like this.  Programs should be quiet unless they got something
> important to say.  Can't see why this particular default is more
> important than all the other defaults we don't print.
> 
> The default could be documented in output of --help.

Actually my thought was this is not using the default value and
implicitly. The default of 'to' is 0, while in this case (when no
display option defined and SDL not configured in), it implicitly uses
non-default value '99'. Therefore I thought it shall be explicitly print
out so that user would be aware of what was chosen on behalf of him;
like the final print of 'VNC server running on '::1;5900''.

[Qemu-devel] [Bug 1535497] [NEW] Guest can not boot up when assigned more than 20 vcpus with option "-no-acpi"

2016-01-18 Thread Robert Hu 
Public bug reported:

Environment:
 ---
 KVM commit/branch: da3f7ca3/next
 Qemu commit/branch: 7b8a354d/master
 Host OS: RHEL7.2 ia32e
 Host Kernel: 4.4-rc2
 Guest OS: RHEL7.2 ia32e

Description:
 
When assign more than 20 vpcus with option "-no-acpi", guest can not boot up.

Reproduce:
 
 1.qemu-system-x86_64 --enable-kvm -m 1024 -smp 20 -no-acpi -device 
virtio-net-pci,netdev=nic0,mac=00:16:3e:17:9b:4c -netdev 
tap,id=nic0,script=/etc/kvm/qemu-ifup -drive 
file=/root/7u2.qcow2,if=none,id=virtio-disk0 -device 
virtio-blk-pci,drive=virtio-disk0


Bisect show the bad commit is 9ee2e2625 of seabios.

** Affects: qemu
 Importance: Undecided
 Status: New

** Attachment added: "host dmesg log"
   https://bugs.launchpad.net/bugs/1535497/+attachment/4552327/+files/dmesg.log

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1535497

Title:
  Guest can not boot up when assigned more than 20 vcpus with option
  "-no-acpi"

Status in QEMU:
  New

Bug description:
  Environment:
   ---
   KVM commit/branch: da3f7ca3/next
   Qemu commit/branch: 7b8a354d/master
   Host OS: RHEL7.2 ia32e
   Host Kernel: 4.4-rc2
   Guest OS: RHEL7.2 ia32e

  Description:
   
  When assign more than 20 vpcus with option "-no-acpi", guest can not boot up.

  Reproduce:
   
   1.qemu-system-x86_64 --enable-kvm -m 1024 -smp 20 -no-acpi -device 
virtio-net-pci,netdev=nic0,mac=00:16:3e:17:9b:4c -netdev 
tap,id=nic0,script=/etc/kvm/qemu-ifup -drive 
file=/root/7u2.qcow2,if=none,id=virtio-disk0 -device 
virtio-blk-pci,drive=virtio-disk0

  
  Bisect show the bad commit is 9ee2e2625 of seabios.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1535497/+subscriptions

[Qemu-devel] [Bug 1535497] Re: Guest can not boot up when assigned more than 20 vcpus with option "-no-acpi"

2016-01-18 Thread Robert Hu 
** Attachment added: "guest log"
   
https://bugs.launchpad.net/qemu/+bug/1535497/+attachment/4552328/+files/guest.log

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1535497

Title:
  Guest can not boot up when assigned more than 20 vcpus with option
  "-no-acpi"

Status in QEMU:
  New

Bug description:
  Environment:
   ---
   KVM commit/branch: da3f7ca3/next
   Qemu commit/branch: 7b8a354d/master
   Host OS: RHEL7.2 ia32e
   Host Kernel: 4.4-rc2
   Guest OS: RHEL7.2 ia32e

  Description:
   
  When assign more than 20 vpcus with option "-no-acpi", guest can not boot up.

  Reproduce:
   
   1.qemu-system-x86_64 --enable-kvm -m 1024 -smp 20 -no-acpi -device 
virtio-net-pci,netdev=nic0,mac=00:16:3e:17:9b:4c -netdev 
tap,id=nic0,script=/etc/kvm/qemu-ifup -drive 
file=/root/7u2.qcow2,if=none,id=virtio-disk0 -device 
virtio-blk-pci,drive=virtio-disk0

  
  Bisect show the bad commit is 9ee2e2625 of seabios.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1535497/+subscriptions

[Qemu-devel] [Bug 1529187] Re: vfio passtrhough fails at 'No available IOMMU models' on Intel BDW-EP platform

2015-12-27 Thread Robert Hu 
You're right. After I manually load vfio_iommu_type1, the error is gone.

** Changed in: qemu
   Status: New => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1529187

Title:
  vfio passtrhough fails at 'No available IOMMU models' on Intel BDW-EP
  platform

Status in QEMU:
  Invalid

Bug description:
  Environment:
   
   Host OS (ia32/ia32e/IA64): ia32e
   Guest OS (ia32/ia32e/IA64): ia32e
   Guest OS Type (Linux/Windows): linux
   kvm.git Commit: da3f7ca3
   qemu.git Commit: 38a762fe 
   Host Kernel Version: 4.4.0-rc2
   Hardware: BDW EP (Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz, Grantley-EP)

  Bug description:
   --
   when create guest with vt-d assignment using vfio-pci driver, the guest can 
not be created.
  Warning 'No available IOMMU models'

  
  Reproduce steps:
   
   1. bind device to vfio-pci driver
   2. qemu-system-x86_64 -enable-kvm -m 512 -smp 2 -device 
vfio-pci,host=81:00.0 -net none -drive 
file=rhel7u2.qcow2,if=none,id=virtio-disk0 -device 
virtio-blk-pci,drive=virtio-disk0

  Current result:
   
   qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: No available IOMMU 
models
   qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to setup 
container for group 41
   qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to get group 
41
   qemu-system-x86_64: -device vfio-pci,host=81:00.0: Device initialization 
failed

  Expected result:
   
   guest can be created
  Basic root-causing log:
   --
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1529187/+subscriptions

[Qemu-devel] [Bug 1529187] [NEW] vfio passtrhough fails at 'No available IOMMU models' on Intel BDW-EP platform

2015-12-24 Thread Robert Hu 
Public bug reported:

Environment:
 
 Host OS (ia32/ia32e/IA64): ia32e
 Guest OS (ia32/ia32e/IA64): ia32e
 Guest OS Type (Linux/Windows): linux
 kvm.git Commit: da3f7ca3
 qemu.git Commit: 38a762fe 
 Host Kernel Version: 4.4.0-rc2
 Hardware: BDW EP (Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz, Grantley-EP)

Bug description:
 --
 when create guest with vt-d assignment using vfio-pci driver, the guest can 
not be created.
Warning 'No available IOMMU models'


Reproduce steps:
 
 1. bind device to vfio-pci driver
 2. qemu-system-x86_64 -enable-kvm -m 512 -smp 2 -device vfio-pci,host=81:00.0 
-net none -drive file=rhel7u2.qcow2,if=none,id=virtio-disk0 -device 
virtio-blk-pci,drive=virtio-disk0

Current result:
 
 qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: No available IOMMU 
models
 qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to setup 
container for group 41
 qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to get group 41
 qemu-system-x86_64: -device vfio-pci,host=81:00.0: Device initialization failed

Expected result:
 
 guest can be created
Basic root-causing log:
 --


** Affects: qemu
 Importance: Undecided
 Status: New

** Attachment added: "host dmesg"
   https://bugs.launchpad.net/bugs/1529187/+attachment/4540026/+files/dmesg.log

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1529187

Title:
  vfio passtrhough fails at 'No available IOMMU models' on Intel BDW-EP
  platform

Status in QEMU:
  New

Bug description:
  Environment:
   
   Host OS (ia32/ia32e/IA64): ia32e
   Guest OS (ia32/ia32e/IA64): ia32e
   Guest OS Type (Linux/Windows): linux
   kvm.git Commit: da3f7ca3
   qemu.git Commit: 38a762fe 
   Host Kernel Version: 4.4.0-rc2
   Hardware: BDW EP (Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz, Grantley-EP)

  Bug description:
   --
   when create guest with vt-d assignment using vfio-pci driver, the guest can 
not be created.
  Warning 'No available IOMMU models'

  
  Reproduce steps:
   
   1. bind device to vfio-pci driver
   2. qemu-system-x86_64 -enable-kvm -m 512 -smp 2 -device 
vfio-pci,host=81:00.0 -net none -drive 
file=rhel7u2.qcow2,if=none,id=virtio-disk0 -device 
virtio-blk-pci,drive=virtio-disk0

  Current result:
   
   qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: No available IOMMU 
models
   qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to setup 
container for group 41
   qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to get group 
41
   qemu-system-x86_64: -device vfio-pci,host=81:00.0: Device initialization 
failed

  Expected result:
   
   guest can be created
  Basic root-causing log:
   --
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1529187/+subscriptions

[Qemu-devel] [Bug 1297651] Re: KVM create a win7 guest with Qemu, it boots up fail

2014-03-27 Thread Robert Hu 
[root@localhost qemu]# git branch -a
* master
  remotes/origin/HEAD - origin/master
  remotes/origin/master
[root@localhost qemu]# git log db237e33
commit db237e33c08a279f0179f8f5128a6d10d9adc38a
Merge: 61898bc ad1c7e0
Author: Peter Maydell peter.mayd...@linaro.org
Date:   Wed Mar 26 17:10:15 2014 +

Merge remote-tracking branch 'remotes/riku/for-2.0' into staging

* remotes/riku/for-2.0:
  linux-user: Correct DLINFO_ITEMS

Signed-off-by: Peter Maydell peter.mayd...@linaro.org

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1297651

Title:
  KVM create a win7 guest with Qemu, it boots up fail

Status in QEMU:
  New

Bug description:
  Environment:
  
  Host OS (ia32/ia32e/IA64):ia32e
  Guest OS (ia32/ia32e/IA64):ia32e
  Guest OS Type (Linux/Windows):Windows
  kvm.git Commit:94b3ffcd41a90d2cb0b32ca23aa58a0d5dc0
  qemu-kvm Commit:839a5547574e57cce62f49bfc50fe1f04b00589a
  Host Kernel Version:3.14.0-rc3
  Hardware:Romley_EP, Ivytown_EP, HSW_EP

  
  Bug detailed description:
  --
  when create a win7 guest, the guest boot up fail.

  note: 
  1. when create win2000, winxp, win2k3, win2k8, guest, the guest boot up fail.
  2. when create win8, win8.1, win2012 guest, the guest boot up fine.

  
  Reproduce steps:
  
  1.create guest
  qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net none -hda /root/win7.qcow

  
  Current result:
  
  win7 guest boot up fail

  Expected result:
  
  win7 guest boot up fine

  Basic root-causing log:
  --

  This should be a qemu bug
  kvm  + qemu =  result
  94b3ffcd + 839a5547 = bad
  94b3ffcd + 3a87f8b6 = good

  the first bad commit is:
  commit 9bcc80cd71892df42605e0c097d85c0237ff45d1
  Author: Laszlo Ersek ler...@redhat.com
  Date:   Mon Mar 17 17:05:16 2014 +0100

  i386/acpi-build: allow more than 255 elements in CPON

  The build_ssdt() function builds a number of AML objects that are related
  to CPU hotplug, and whose IDs form a contiguous sequence of APIC IDs.
  (APIC IDs are in fact discontiguous, but this is the traditional
  interface: build a contiguous sequence from zero up that covers all
  possible APIC IDs.) These objects are:

  - a Processor() object for each VCPU,
  - a NTFY method, with one branch for each VCPU,
  - a CPON package with one element (hotplug status byte) for each VCPU.

  The build_ssdt() function currently limits the *count* of processor
  objects, and NTFY branches, and CPON elements, in 0xFF (see the assignment
  to acpi_cpus). This allows for an inclusive APIC ID range of [0..254].
  This is incorrect, because the highest APIC ID that we otherwise allow a
  VCPU to take is 255.

  In order to extend the maximum count to 256, and the traversed APIC ID
  range correspondingly to [0..255]:
  - the Processor() objects need no change,
  - the NTFY method also needs no change,
  - the CPON package must be updated, because it is defined with a
DefPackage, and the number of elements in such a package can be at most
255. We pick a DefVarPackage instead.

  We replace the Op byte, and the encoding of the number of elements.
  Compare:

  DefPackage := PackageOpPkgLength NumElementsPackageElementList
  DefVarPackage  := VarPackageOp PkgLength VarNumElements PackageElementList

  PackageOp  := 0x12
  VarPackageOp   := 0x13

  NumElements:= ByteData
  VarNumElements := TermArg = Integer

  The build_append_int() function implements precisely the following TermArg
  encodings (a subset of what the ACPI spec describes):

TermArg := DataObject
DataObject  := ComputationalData
ComputationalData   := ConstObj | ByteConst | WordConst | DWordConst
directly encoded in the function, with build_append_byte():
  ConstObj  := ZeroOp | OneOp
ZeroOp  := 0x00
OneOp   := 0x01

call to build_append_value(..., 1):
  ByteConst := BytePrefix ByteData
BytePrefix  := 0x0A
ByteData:= 0x00 - 0xFF

call to build_append_value(..., 2):
  WordConst := WordPrefix WordData
WordPrefix  := 0x0B
WordData:= ByteData[0:7] ByteData[8:15]

call to build_append_value(..., 4):
  DWordConst:= DWordPrefix DWordData
DWordPrefix := 0x0C
DWordData   := WordData[0:15] WordData[16:31]

  Signed-off-by: Laszlo Ersek ler...@redhat.com
  Reviewed-by: Michael S. Tsirkin m...@redhat.com
  Signed-off-by: Michael S. Tsirkin m...@redhat.com

To manage notifications about this bug go to:

[Qemu-devel] [Bug 1297651] [NEW] KVM create a win7 guest with Qemu, it boots up fail

2014-03-26 Thread Robert Hu 
Public bug reported:

Environment:

Host OS (ia32/ia32e/IA64):ia32e
Guest OS (ia32/ia32e/IA64):ia32e
Guest OS Type (Linux/Windows):Windows
kvm.git Commit:94b3ffcd41a90d2cb0b32ca23aa58a0d5dc0
qemu-kvm Commit:839a5547574e57cce62f49bfc50fe1f04b00589a
Host Kernel Version:3.14.0-rc3
Hardware:Romley_EP, Ivytown_EP, HSW_EP


Bug detailed description:
--
when create a win7 guest, the guest boot up fail.

note: 
1. when create win2000, winxp, win2k3, win2k8, guest, the guest boot up fail.
2. when create win8, win8.1, win2012 guest, the guest boot up fine.


Reproduce steps:

1.create guest
qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net none -hda /root/win7.qcow


Current result:

win7 guest boot up fail

Expected result:

win7 guest boot up fine

Basic root-causing log:
--

This should be a qemu bug
kvm  + qemu =  result
94b3ffcd + 839a5547 = bad
94b3ffcd + 3a87f8b6 = good

the first bad commit is:
commit 9bcc80cd71892df42605e0c097d85c0237ff45d1
Author: Laszlo Ersek ler...@redhat.com
Date:   Mon Mar 17 17:05:16 2014 +0100

i386/acpi-build: allow more than 255 elements in CPON

The build_ssdt() function builds a number of AML objects that are related
to CPU hotplug, and whose IDs form a contiguous sequence of APIC IDs.
(APIC IDs are in fact discontiguous, but this is the traditional
interface: build a contiguous sequence from zero up that covers all
possible APIC IDs.) These objects are:

- a Processor() object for each VCPU,
- a NTFY method, with one branch for each VCPU,
- a CPON package with one element (hotplug status byte) for each VCPU.

The build_ssdt() function currently limits the *count* of processor
objects, and NTFY branches, and CPON elements, in 0xFF (see the assignment
to acpi_cpus). This allows for an inclusive APIC ID range of [0..254].
This is incorrect, because the highest APIC ID that we otherwise allow a
VCPU to take is 255.

In order to extend the maximum count to 256, and the traversed APIC ID
range correspondingly to [0..255]:
- the Processor() objects need no change,
- the NTFY method also needs no change,
- the CPON package must be updated, because it is defined with a
  DefPackage, and the number of elements in such a package can be at most
  255. We pick a DefVarPackage instead.

We replace the Op byte, and the encoding of the number of elements.
Compare:

DefPackage := PackageOpPkgLength NumElementsPackageElementList
DefVarPackage  := VarPackageOp PkgLength VarNumElements PackageElementList

PackageOp  := 0x12
VarPackageOp   := 0x13

NumElements:= ByteData
VarNumElements := TermArg = Integer

The build_append_int() function implements precisely the following TermArg
encodings (a subset of what the ACPI spec describes):

  TermArg := DataObject
  DataObject  := ComputationalData
  ComputationalData   := ConstObj | ByteConst | WordConst | DWordConst
  directly encoded in the function, with build_append_byte():
ConstObj  := ZeroOp | OneOp
  ZeroOp  := 0x00
  OneOp   := 0x01

  call to build_append_value(..., 1):
ByteConst := BytePrefix ByteData
  BytePrefix  := 0x0A
  ByteData:= 0x00 - 0xFF

  call to build_append_value(..., 2):
WordConst := WordPrefix WordData
  WordPrefix  := 0x0B
  WordData:= ByteData[0:7] ByteData[8:15]

  call to build_append_value(..., 4):
DWordConst:= DWordPrefix DWordData
  DWordPrefix := 0x0C
  DWordData   := WordData[0:15] WordData[16:31]

Signed-off-by: Laszlo Ersek ler...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1297651

Title:
  KVM create a win7 guest with Qemu, it boots up fail

Status in QEMU:
  New

Bug description:
  Environment:
  
  Host OS (ia32/ia32e/IA64):ia32e
  Guest OS (ia32/ia32e/IA64):ia32e
  Guest OS Type (Linux/Windows):Windows
  kvm.git Commit:94b3ffcd41a90d2cb0b32ca23aa58a0d5dc0
  qemu-kvm Commit:839a5547574e57cce62f49bfc50fe1f04b00589a
  Host Kernel Version:3.14.0-rc3
  Hardware:Romley_EP, Ivytown_EP, HSW_EP

  
  Bug detailed description:
  --
  when create a win7 guest, the guest boot up fail.

  note: 
  1. when create win2000, winxp, win2k3, win2k8, guest, the guest boot up fail.
  2. when create win8, win8.1, win2012 guest, the guest boot up fine.

  
  Reproduce steps:
  
  1.create guest
  qemu-system-x86_64

[Qemu-devel] [Bug 1297651] Re: KVM create a win7 guest with Qemu, it boots up fail

2014-03-26 Thread Robert Hu 
on latest commit (db237e33), this bug doesn't exit.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1297651

Title:
  KVM create a win7 guest with Qemu, it boots up fail

Status in QEMU:
  New

Bug description:
  Environment:
  
  Host OS (ia32/ia32e/IA64):ia32e
  Guest OS (ia32/ia32e/IA64):ia32e
  Guest OS Type (Linux/Windows):Windows
  kvm.git Commit:94b3ffcd41a90d2cb0b32ca23aa58a0d5dc0
  qemu-kvm Commit:839a5547574e57cce62f49bfc50fe1f04b00589a
  Host Kernel Version:3.14.0-rc3
  Hardware:Romley_EP, Ivytown_EP, HSW_EP

  
  Bug detailed description:
  --
  when create a win7 guest, the guest boot up fail.

  note: 
  1. when create win2000, winxp, win2k3, win2k8, guest, the guest boot up fail.
  2. when create win8, win8.1, win2012 guest, the guest boot up fine.

  
  Reproduce steps:
  
  1.create guest
  qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net none -hda /root/win7.qcow

  
  Current result:
  
  win7 guest boot up fail

  Expected result:
  
  win7 guest boot up fine

  Basic root-causing log:
  --

  This should be a qemu bug
  kvm  + qemu =  result
  94b3ffcd + 839a5547 = bad
  94b3ffcd + 3a87f8b6 = good

  the first bad commit is:
  commit 9bcc80cd71892df42605e0c097d85c0237ff45d1
  Author: Laszlo Ersek ler...@redhat.com
  Date:   Mon Mar 17 17:05:16 2014 +0100

  i386/acpi-build: allow more than 255 elements in CPON

  The build_ssdt() function builds a number of AML objects that are related
  to CPU hotplug, and whose IDs form a contiguous sequence of APIC IDs.
  (APIC IDs are in fact discontiguous, but this is the traditional
  interface: build a contiguous sequence from zero up that covers all
  possible APIC IDs.) These objects are:

  - a Processor() object for each VCPU,
  - a NTFY method, with one branch for each VCPU,
  - a CPON package with one element (hotplug status byte) for each VCPU.

  The build_ssdt() function currently limits the *count* of processor
  objects, and NTFY branches, and CPON elements, in 0xFF (see the assignment
  to acpi_cpus). This allows for an inclusive APIC ID range of [0..254].
  This is incorrect, because the highest APIC ID that we otherwise allow a
  VCPU to take is 255.

  In order to extend the maximum count to 256, and the traversed APIC ID
  range correspondingly to [0..255]:
  - the Processor() objects need no change,
  - the NTFY method also needs no change,
  - the CPON package must be updated, because it is defined with a
DefPackage, and the number of elements in such a package can be at most
255. We pick a DefVarPackage instead.

  We replace the Op byte, and the encoding of the number of elements.
  Compare:

  DefPackage := PackageOpPkgLength NumElementsPackageElementList
  DefVarPackage  := VarPackageOp PkgLength VarNumElements PackageElementList

  PackageOp  := 0x12
  VarPackageOp   := 0x13

  NumElements:= ByteData
  VarNumElements := TermArg = Integer

  The build_append_int() function implements precisely the following TermArg
  encodings (a subset of what the ACPI spec describes):

TermArg := DataObject
DataObject  := ComputationalData
ComputationalData   := ConstObj | ByteConst | WordConst | DWordConst
directly encoded in the function, with build_append_byte():
  ConstObj  := ZeroOp | OneOp
ZeroOp  := 0x00
OneOp   := 0x01

call to build_append_value(..., 1):
  ByteConst := BytePrefix ByteData
BytePrefix  := 0x0A
ByteData:= 0x00 - 0xFF

call to build_append_value(..., 2):
  WordConst := WordPrefix WordData
WordPrefix  := 0x0B
WordData:= ByteData[0:7] ByteData[8:15]

call to build_append_value(..., 4):
  DWordConst:= DWordPrefix DWordData
DWordPrefix := 0x0C
DWordData   := WordData[0:15] WordData[16:31]

  Signed-off-by: Laszlo Ersek ler...@redhat.com
  Reviewed-by: Michael S. Tsirkin m...@redhat.com
  Signed-off-by: Michael S. Tsirkin m...@redhat.com

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1297651/+subscriptions

[Qemu-devel] [Bug 1293975] Re: Guest is destroyed after live migration

2014-03-24 Thread Robert Hu 
kvm.git + qemu.git: 94b3ffcd_f71e769d
after live migration, the guest works fine.

** Changed in: qemu
   Status: New = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1293975

Title:
  Guest is destroyed after live migration

Status in QEMU:
  Fix Released

Bug description:
  Environment:
  
  Host OS (ia32/ia32e/IA64):ia32e
  Guest OS (ia32/ia32e/IA64):ia32e
  Guest OS Type (Linux/Windows):Linux
  kvm.git Commit:8fbb1daf3e8254afc17fc4490b69db00920197ae
  qemu.git Commit: 6fffa26244737f8fd8641a21fee29bd6aa9fdff5
  Host Kernel Version:3.14.0-rc3
  Hardware:Romley_EP, Ivytown_EP

  
  Bug detailed description:
  --
  after live migration, the guest will be destroyed

  note:
  after save restore, the guest will be destroyed.

  Reproduce steps:
  
  1.Start a TCP daemon for migration
  qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -net none /root/rhel6u4.qcow 
-incoming tcp:localhost:
  2. create guest
  qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -net none /root/rhel6u4.qcow 
  3. ctrl+alt+2 to switch to qemu monitor
  4. migrate tcp:localhost:

  Current result:
  
  the guest will be destroyed

  Expected result:
  
  the guest works fine

  Basic root-causing log:
  --
  qemu-system-x86[15027]: segfault at 698 ip 7f94be628166 sp 
7f94bb820c58 error 6 in libc-2.12.so[7f94be5a5000+189000]

  
  Bisect result
  the first bad commit:
  commit 00c8cb0a36f51a6866a83c08962d12a0eb21864b
  Author: Andreas Färber afaer...@suse.de
  Date:   Wed Sep 4 02:19:44 2013 +0200

  cputlb: Change tlb_flush() argument to CPUState

  Signed-off-by: Andreas Färber afaer...@suse.de

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1293975/+subscriptions

[Qemu-devel] [Bug 1293975] [NEW] Guest is destroyed after live migration

2014-03-18 Thread Robert Hu 
Public bug reported:

Environment:

Host OS (ia32/ia32e/IA64):ia32e
Guest OS (ia32/ia32e/IA64):ia32e
Guest OS Type (Linux/Windows):Linux
kvm.git Commit:8fbb1daf3e8254afc17fc4490b69db00920197ae
qemu.git Commit: 6fffa26244737f8fd8641a21fee29bd6aa9fdff5
Host Kernel Version:3.14.0-rc3
Hardware:Romley_EP, Ivytown_EP


Bug detailed description:
--
after live migration, the guest will be destroyed

note:
after save restore, the guest will be destroyed.

Reproduce steps:

1.Start a TCP daemon for migration
qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -net none /root/rhel6u4.qcow 
-incoming tcp:localhost:
2. create guest
qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -net none /root/rhel6u4.qcow 
3. ctrl+alt+2 to switch to qemu monitor
4. migrate tcp:localhost:

Current result:

the guest will be destroyed

Expected result:

the guest works fine

Basic root-causing log:
--
qemu-system-x86[15027]: segfault at 698 ip 7f94be628166 sp 7f94bb820c58 
error 6 in libc-2.12.so[7f94be5a5000+189000]


Bisect result
the first bad commit:
commit 00c8cb0a36f51a6866a83c08962d12a0eb21864b
Author: Andreas Färber afaer...@suse.de
Date:   Wed Sep 4 02:19:44 2013 +0200

cputlb: Change tlb_flush() argument to CPUState

Signed-off-by: Andreas Färber afaer...@suse.de

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1293975

Title:
  Guest is destroyed after live migration

Status in QEMU:
  New

Bug description:
  Environment:
  
  Host OS (ia32/ia32e/IA64):ia32e
  Guest OS (ia32/ia32e/IA64):ia32e
  Guest OS Type (Linux/Windows):Linux
  kvm.git Commit:8fbb1daf3e8254afc17fc4490b69db00920197ae
  qemu.git Commit: 6fffa26244737f8fd8641a21fee29bd6aa9fdff5
  Host Kernel Version:3.14.0-rc3
  Hardware:Romley_EP, Ivytown_EP

  
  Bug detailed description:
  --
  after live migration, the guest will be destroyed

  note:
  after save restore, the guest will be destroyed.

  Reproduce steps:
  
  1.Start a TCP daemon for migration
  qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -net none /root/rhel6u4.qcow 
-incoming tcp:localhost:
  2. create guest
  qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -net none /root/rhel6u4.qcow 
  3. ctrl+alt+2 to switch to qemu monitor
  4. migrate tcp:localhost:

  Current result:
  
  the guest will be destroyed

  Expected result:
  
  the guest works fine

  Basic root-causing log:
  --
  qemu-system-x86[15027]: segfault at 698 ip 7f94be628166 sp 
7f94bb820c58 error 6 in libc-2.12.so[7f94be5a5000+189000]

  
  Bisect result
  the first bad commit:
  commit 00c8cb0a36f51a6866a83c08962d12a0eb21864b
  Author: Andreas Färber afaer...@suse.de
  Date:   Wed Sep 4 02:19:44 2013 +0200

  cputlb: Change tlb_flush() argument to CPUState

  Signed-off-by: Andreas Färber afaer...@suse.de

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1293975/+subscriptions