[Bug 1887854] [NEW] Spurious Data Abort on qemu-system-aarch64

[K]

Public bug reported:

When running RTEMS test psxndbm01.exe built for AArch64-ilp32 (this code is not 
yet publically available), the test generates a spurious data abort (the MMU 
and alignment checks should be disabled according to bits 1, 0 of SCTLR_EL1). 
The abort information is as follows:
Taking exception 4 [Data Abort]
...from EL1 to EL1
...with ESR 0x25/0x9610
...with FAR 0x104010ca28
...with ELR 0x400195d8
...to EL1 PC 0x40018200 PSTATE 0x3c5

The ESR indicates that a synchronous external abort has occurred.
ESR EC field: 0b100101

>From the ARMv8 technical manual: Data Abort taken without a change in
Exception level. Used for MMU faults generated by data accesses,
alignment faults other than those caused by Stack Pointer misalignment,
and synchronous External aborts, including synchronous parity or ECC
errors. Not used for debug related exceptions.

ESR ISS field: 0b1

>From the ARMv8 technical manual: Synchronous External abort, not on
translation table walk or hardware update of translation table.

The following command line is used to invoke qemu:
qemu-system-aarch64 -machine virt -cpu cortex-a53 -m 256M -no-reboot -nographic 
-serial mon:stdio -kernel 
build/aarch64/a53_ilp32_qemu/testsuites/psxtests/psxndbm01.exe -D qemu.log -d 
in_asm,int,cpu_reset,unimp,guest_errors

This occurs on Qemu 3.1.0 as distributed via Debian and on Qemu 4.1 as
built by the RTEMS source builder (4.1+minor patches).

Edit: This bug can be worked around by getting and setting SCTLR without
changing its value.

** Affects: qemu
 Importance: Undecided
 Status: New

** Attachment added: "Qemu execution log and binary"
   
https://bugs.launchpad.net/bugs/1887854/+attachment/5393233/+files/data_abort.tar.gz

** Description changed:

  When running RTEMS test psxndbm01.exe built for AArch64-ilp32 (this code is 
not yet publically available), the test generates a spurious data abort (the 
MMU and alignment checks should be disabled according to bits 1, 0 of 
SCTLR_EL1). The abort information is as follows:
  Taking exception 4 [Data Abort]
  ...from EL1 to EL1
  ...with ESR 0x25/0x9610
  ...with FAR 0x104010ca28
  ...with ELR 0x400195d8
  ...to EL1 PC 0x40018200 PSTATE 0x3c5
  
  The ESR indicates that a synchronous external abort has occurred.
  ESR EC field: 0b100101
  
  From the ARMv8 technical manual: Data Abort taken without a change in
  Exception level. Used for MMU faults generated by data accesses,
  alignment faults other than those caused by Stack Pointer misalignment,
  and synchronous External aborts, including synchronous parity or ECC
  errors. Not used for debug related exceptions.
  
  ESR ISS field: 0b1
  
  From the ARMv8 technical manual: Synchronous External abort, not on
  translation table walk or hardware update of translation table.
  
  The following command line is used to invoke qemu:
  qemu-system-aarch64 -machine virt -cpu cortex-a53 -m 256M -no-reboot 
-nographic -serial mon:stdio -kernel 
build/aarch64/a53_ilp32_qemu/testsuites/psxtests/psxndbm01.exe -D qemu.log -d 
in_asm,int,cpu_reset,unimp,guest_errors
  
  This occurs on Qemu 3.1.0 as distributed via Debian and on Qemu 4.1 as
  built by the RTEMS source builder (4.1+minor patches).
+ 
+ Edit: This bug can be worked around by getting and setting SCTLR without
+ changing its value.

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

Title:
  Spurious Data Abort on qemu-system-aarch64

Status in QEMU:
  New

Bug description:
  When running RTEMS test psxndbm01.exe built for AArch64-ilp32 (this code is 
not yet publically available), the test generates a spurious data abort (the 
MMU and alignment checks should be disabled according to bits 1, 0 of 
SCTLR_EL1). The abort information is as follows:
  Taking exception 4 [Data Abort]
  ...from EL1 to EL1
  ...with ESR 0x25/0x9610
  ...with FAR 0x104010ca28
  ...with ELR 0x400195d8
  ...to EL1 PC 0x40018200 PSTATE 0x3c5

  The ESR indicates that a synchronous external abort has occurred.
  ESR EC field: 0b100101

  From the ARMv8 technical manual: Data Abort taken without a change in
  Exception level. Used for MMU faults generated by data accesses,
  alignment faults other than those caused by Stack Pointer
  misalignment, and synchronous External aborts, including synchronous
  parity or ECC errors. Not used for debug related exceptions.

  ESR ISS field: 0b1

  From the ARMv8 technical manual: Synchronous External abort, not on
  translation table walk or hardware update of translation table.

  The following command line is used to invoke qemu:
  qemu-system-aarch64 -machine virt -cpu cortex-a53 -m 256M -no-reboot 
-nographic -serial mon:stdio -kernel 
build/aarch64/a53_ilp32_qemu/testsuites/psxtests/psxndbm01.exe -D qemu.log -d 
in_asm,int,cpu_reset,unimp,guest_errors

  This occurs on Qemu 3.1.0 as distributed via Debian and on Qemu 4.1 as
  built by t

[Bug 1887854] Re: Spurious Data Abort on qemu-system-aarch64

[K]

** Description changed:

  When running RTEMS test psxndbm01.exe built for AArch64-ilp32 (this code is 
not yet publically available), the test generates a spurious data abort (the 
MMU and alignment checks should be disabled according to bits 1, 0 of 
SCTLR_EL1). The abort information is as follows:
  Taking exception 4 [Data Abort]
  ...from EL1 to EL1
  ...with ESR 0x25/0x9610
  ...with FAR 0x104010ca28
  ...with ELR 0x400195d8
  ...to EL1 PC 0x40018200 PSTATE 0x3c5
  
  The ESR indicates that a synchronous external abort has occurred.
  ESR EC field: 0b100101
  
  From the ARMv8 technical manual: Data Abort taken without a change in
  Exception level. Used for MMU faults generated by data accesses,
  alignment faults other than those caused by Stack Pointer misalignment,
  and synchronous External aborts, including synchronous parity or ECC
  errors. Not used for debug related exceptions.
  
  ESR ISS field: 0b1
  
  From the ARMv8 technical manual: Synchronous External abort, not on
  translation table walk or hardware update of translation table.
  
  The following command line is used to invoke qemu:
  qemu-system-aarch64 -machine virt -cpu cortex-a53 -m 256M -no-reboot 
-nographic -serial mon:stdio -kernel 
build/aarch64/a53_ilp32_qemu/testsuites/psxtests/psxndbm01.exe -D qemu.log -d 
in_asm,int,cpu_reset,unimp,guest_errors
  
  This occurs on Qemu 3.1.0 as distributed via Debian and on Qemu 4.1 as
  built by the RTEMS source builder (4.1+minor patches).
  
  Edit: This bug can be worked around by getting and setting SCTLR without
- changing its value.
+ changing its value before each data abort would occur. This test needs 6
+ of these workarounds to operate successfully.

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

Title:
  Spurious Data Abort on qemu-system-aarch64

Status in QEMU:
  New

Bug description:
  When running RTEMS test psxndbm01.exe built for AArch64-ilp32 (this code is 
not yet publically available), the test generates a spurious data abort (the 
MMU and alignment checks should be disabled according to bits 1, 0 of 
SCTLR_EL1). The abort information is as follows:
  Taking exception 4 [Data Abort]
  ...from EL1 to EL1
  ...with ESR 0x25/0x9610
  ...with FAR 0x104010ca28
  ...with ELR 0x400195d8
  ...to EL1 PC 0x40018200 PSTATE 0x3c5

  The ESR indicates that a synchronous external abort has occurred.
  ESR EC field: 0b100101

  From the ARMv8 technical manual: Data Abort taken without a change in
  Exception level. Used for MMU faults generated by data accesses,
  alignment faults other than those caused by Stack Pointer
  misalignment, and synchronous External aborts, including synchronous
  parity or ECC errors. Not used for debug related exceptions.

  ESR ISS field: 0b1

  From the ARMv8 technical manual: Synchronous External abort, not on
  translation table walk or hardware update of translation table.

  The following command line is used to invoke qemu:
  qemu-system-aarch64 -machine virt -cpu cortex-a53 -m 256M -no-reboot 
-nographic -serial mon:stdio -kernel 
build/aarch64/a53_ilp32_qemu/testsuites/psxtests/psxndbm01.exe -D qemu.log -d 
in_asm,int,cpu_reset,unimp,guest_errors

  This occurs on Qemu 3.1.0 as distributed via Debian and on Qemu 4.1 as
  built by the RTEMS source builder (4.1+minor patches).

  Edit: This bug can be worked around by getting and setting SCTLR
  without changing its value before each data abort would occur. This
  test needs 6 of these workarounds to operate successfully.

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

[Bug 1887854] Re: Spurious Data Abort on qemu-system-aarch64

[K]

I would have thought that TLB considerations would not apply when the
MMU is disabled (RTEMS runs in a completely flat memory space). I'll try
to reproduce on more modern QEMU today. Thanks for taking a look at
this.

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

Title:
  Spurious Data Abort on qemu-system-aarch64

Status in QEMU:
  New

Bug description:
  When running RTEMS test psxndbm01.exe built for AArch64-ilp32 (this code is 
not yet publically available), the test generates a spurious data abort (the 
MMU and alignment checks should be disabled according to bits 1, 0 of 
SCTLR_EL1). The abort information is as follows:
  Taking exception 4 [Data Abort]
  ...from EL1 to EL1
  ...with ESR 0x25/0x9610
  ...with FAR 0x104010ca28
  ...with ELR 0x400195d8
  ...to EL1 PC 0x40018200 PSTATE 0x3c5

  The ESR indicates that a synchronous external abort has occurred.
  ESR EC field: 0b100101

  From the ARMv8 technical manual: Data Abort taken without a change in
  Exception level. Used for MMU faults generated by data accesses,
  alignment faults other than those caused by Stack Pointer
  misalignment, and synchronous External aborts, including synchronous
  parity or ECC errors. Not used for debug related exceptions.

  ESR ISS field: 0b1

  From the ARMv8 technical manual: Synchronous External abort, not on
  translation table walk or hardware update of translation table.

  The following command line is used to invoke qemu:
  qemu-system-aarch64 -machine virt -cpu cortex-a53 -m 256M -no-reboot 
-nographic -serial mon:stdio -kernel 
build/aarch64/a53_ilp32_qemu/testsuites/psxtests/psxndbm01.exe -D qemu.log -d 
in_asm,int,cpu_reset,unimp,guest_errors

  This occurs on Qemu 3.1.0 as distributed via Debian and on Qemu 4.1 as
  built by the RTEMS source builder (4.1+minor patches).

  Edit: This bug can be worked around by getting and setting SCTLR
  without changing its value before each data abort would occur. This
  test needs 6 of these workarounds to operate successfully.

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

[Bug 1887854] Re: Spurious Data Abort on qemu-system-aarch64

[K]

Ok, thanks for rooting this out. I could swear that I checked that
address several times and I clearly remember 0x4010ca28, but I don't
remember ever seeing 0x10 ahead of it. I'll dig into it a bit and
hopefully find the root cause in my code.

** 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/1887854

Title:
  Spurious Data Abort on qemu-system-aarch64

Status in QEMU:
  Invalid

Bug description:
  When running RTEMS test psxndbm01.exe built for AArch64-ilp32 (this code is 
not yet publically available), the test generates a spurious data abort (the 
MMU and alignment checks should be disabled according to bits 1, 0 of 
SCTLR_EL1). The abort information is as follows:
  Taking exception 4 [Data Abort]
  ...from EL1 to EL1
  ...with ESR 0x25/0x9610
  ...with FAR 0x104010ca28
  ...with ELR 0x400195d8
  ...to EL1 PC 0x40018200 PSTATE 0x3c5

  The ESR indicates that a synchronous external abort has occurred.
  ESR EC field: 0b100101

  From the ARMv8 technical manual: Data Abort taken without a change in
  Exception level. Used for MMU faults generated by data accesses,
  alignment faults other than those caused by Stack Pointer
  misalignment, and synchronous External aborts, including synchronous
  parity or ECC errors. Not used for debug related exceptions.

  ESR ISS field: 0b1

  From the ARMv8 technical manual: Synchronous External abort, not on
  translation table walk or hardware update of translation table.

  The following command line is used to invoke qemu:
  qemu-system-aarch64 -machine virt -cpu cortex-a53 -m 256M -no-reboot 
-nographic -serial mon:stdio -kernel 
build/aarch64/a53_ilp32_qemu/testsuites/psxtests/psxndbm01.exe -D qemu.log -d 
in_asm,int,cpu_reset,unimp,guest_errors

  This occurs on Qemu 3.1.0 as distributed via Debian and on Qemu 4.1 as
  built by the RTEMS source builder (4.1+minor patches).

  Edit: This bug can be worked around by getting and setting SCTLR
  without changing its value before each data abort would occur. This
  test needs 6 of these workarounds to operate successfully.

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

[Bug 1887854] Re: Spurious Data Abort on qemu-system-aarch64

[K]

An update for anyone interested: I didn't remember seeing the leading
0x10 because the values are correct when retrieved from memory. They get
packed into a structure that gets returned in a single register, so the
0x10 second element ends up in the upper 4 bytes of x0 which is provided
as the first argument to strcmp. strcmp doesn't appear to clear the
upper bytes of x0 in ilp32 mode before using it to access memory. This
issue is actually either a GCC codegen problem or a multilib selection
problem in the build environment.

Also of note, GDB prints the full 64bit address when printing $w0
instead of the lower 4 bytes, but I don't think that's a Qemu bug
either.

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

Title:
  Spurious Data Abort on qemu-system-aarch64

Status in QEMU:
  Invalid

Bug description:
  When running RTEMS test psxndbm01.exe built for AArch64-ilp32 (this code is 
not yet publically available), the test generates a spurious data abort (the 
MMU and alignment checks should be disabled according to bits 1, 0 of 
SCTLR_EL1). The abort information is as follows:
  Taking exception 4 [Data Abort]
  ...from EL1 to EL1
  ...with ESR 0x25/0x9610
  ...with FAR 0x104010ca28
  ...with ELR 0x400195d8
  ...to EL1 PC 0x40018200 PSTATE 0x3c5

  The ESR indicates that a synchronous external abort has occurred.
  ESR EC field: 0b100101

  From the ARMv8 technical manual: Data Abort taken without a change in
  Exception level. Used for MMU faults generated by data accesses,
  alignment faults other than those caused by Stack Pointer
  misalignment, and synchronous External aborts, including synchronous
  parity or ECC errors. Not used for debug related exceptions.

  ESR ISS field: 0b1

  From the ARMv8 technical manual: Synchronous External abort, not on
  translation table walk or hardware update of translation table.

  The following command line is used to invoke qemu:
  qemu-system-aarch64 -machine virt -cpu cortex-a53 -m 256M -no-reboot 
-nographic -serial mon:stdio -kernel 
build/aarch64/a53_ilp32_qemu/testsuites/psxtests/psxndbm01.exe -D qemu.log -d 
in_asm,int,cpu_reset,unimp,guest_errors

  This occurs on Qemu 3.1.0 as distributed via Debian and on Qemu 4.1 as
  built by the RTEMS source builder (4.1+minor patches).

  Edit: This bug can be worked around by getting and setting SCTLR
  without changing its value before each data abort would occur. This
  test needs 6 of these workarounds to operate successfully.

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

[Qemu-devel] tracing guest memory access

[Ilia K.]

Hi,
I need to trace all data loads/stores of a guest OS running under qemu (for
now, both guest and host are x86-64, and virtual addresses should be
sufficient). Looking into qemu-devel archive I see that this subject is
brought up not very frequently, but regularly. I know, there is a general
tracing support, but I am not sure how suitable it is for such high-volume
tracing. Also, some TCG hacking is needed for this to work. Several people
has tackled with the subject, particularly, Lluís Vilanova, who still may
be around in this mailing list (or should I CC him?). However, I do not see
a relevant code in git master.

Anybody knows what is a current state of guest tracing under qemu?
Any pointers to official/unofficial git repos with a (partial)
implementation?

--
Thanks,
Ilia.

Re: [Qemu-devel] [PATCH] qga: Fix handle fd leak in acquire_privilege()

[Wangrui (K)]

> -Original Message-
> From: Yan Vugenfirer [mailto:yvuge...@redhat.com]
> Sent: Wednesday, May 21, 2014 5:01 PM
> To: Michael Roth
> Cc: Luiz Capitulino; Wangrui (K); Gonglei (Arei); qemu-devel@nongnu.org;
> arm...@redhat.com
> Subject: Re: [Qemu-devel] [PATCH] qga: Fix handle fd leak in 
> acquire_privilege()
> 
> 
> On May 20, 2014, at 10:46 PM, Michael Roth 
> wrote:
> 
> > Quoting Luiz Capitulino (2014-05-20 14:17:42)
> >> On Mon, 19 May 2014 15:26:03 +0800
> >>  wrote:
> >>
> >>> From: Gonglei 
> >>>
> >>> token should be closed in all conditions.
> >>> So move CloseHandle(token) to "out" branch.
> >>
> >> Looks good to me. Michael, are you going to pick this one?
> >
> > Sure I'll queue it. Though i'm a bit surprised OpenProcessToken() will still
> > return an open handle on failure. Is there any confirmation a handle is
> > actually getting leaked here, as opposed to just returning a handle that's
> > already been closed?
> 
> It won't return a handle if it failed (I actually was going to reject the 
> patch
> because of it) - but if you look closely at the code you will see error cases 
> after
> OpenProcessToken was successful where we jump out of the if scope and then
> CloseHandle won't be called.
> 

Yep.
The two "goto out"s are in the condition that OpenProcessToken returns 
successfully.

> Best regards,
> Yan.
> 
> >
> > If it's the latter case we might end up closing it twice after the change,
> > so just want to confirm.
> >
> >>
> >>>
> >>> Signed-off-by: Wang Rui 
> >>> Signed-off-by: Gonglei 
> >>> ---
> >>> qga/commands-win32.c | 6 --
> >>> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/qga/commands-win32.c b/qga/commands-win32.c
> >>> index d793dd0..e769396 100644
> >>> --- a/qga/commands-win32.c
> >>> +++ b/qga/commands-win32.c
> >>> @@ -31,7 +31,7 @@
> >>>
> >>> static void acquire_privilege(const char *name, Error **errp)
> >>> {
> >>> -HANDLE token;
> >>> +HANDLE token = NULL;
> >>> TOKEN_PRIVILEGES priv;
> >>> Error *local_err = NULL;
> >>>
> >>> @@ -53,13 +53,15 @@ static void acquire_privilege(const char *name,
> Error **errp)
> >>> goto out;
> >>> }
> >>>
> >>> -CloseHandle(token);
> >>> } else {
> >>> error_set(&local_err, QERR_QGA_COMMAND_FAILED,
> >>>   "failed to open privilege token");
> >>> }
> >>>
> >>> out:
> >>> +if (token) {
> >>> +CloseHandle(token);
> >>> +}
> >>> if (local_err) {
> >>> error_propagate(errp, local_err);
> >>> }
> >
> >

[Qemu-devel] emulation support for the avoton processor

[Srikanth K]

Hi All,
   I am looking for a way to emulate avoton processor.  Is there
any pre-defined configuration to simulate an avoton based board with qemu?

   At this point of time, I am trying to experiment with the various i2c
SoC, LPC of the processor.

   Any pointers to jump start with this would be appreciated.

Thanks
Srikanth

[Qemu-devel] Fwd: emulation support for the avoton processor

[Srikanth K]

Hi All,
I am looking for a way to emulate avoton processor.  Is there
any pre-defined configuration to simulate an avoton based board with qemu?

   At this point of time, I am trying to experiment with the various i2c
SoC, LPC of the processor.

   Any pointers to jump start with this would be appreciated.

Thanks
Srikanth

Re: [Qemu-devel] qemu-ga: How to static compilation qemu-ga.exe for windows on fedora 18

[Wangrui (K)]

Any ideas about the issue ?

Regards.

> -Original Message-
> From: Gonglei (Arei)
> Sent: Wednesday, April 16, 2014 10:05 AM
> To: qemu-devel@nongnu.org
> Cc: mdr...@linux.vnet.ibm.com; Wangrui (K)
> Subject: qemu-ga: How to static compilation qemu-ga.exe for windows on
> fedora 18
> 
> Hi,
> 
> I'm using qemu-ga.exe in windows server 2008 R2 64.
> I want to use it without libraries such as iconv.dll, libglib-2.0-0.dll, 
> libintl-8.dll
> and libssp-0.dll
> 
> So I use static compilation on fedora 18.
> 
> build qemu-1.7.0:
>  # for Windows using MinGW on linux (Fedora 18)
>  ./configure --enable-guest-agent --cross-prefix=x86_64-w64-mingw32- --static
>  make qemu-ga.exe
> 
> Build success as expected.
> But qemu-ga.exe runs error when it steps to the first glib library function 
> (such
> as g_malloc).
> 
> Problem Event Name:  BEX64
> Application Name:  qemu-ga.exe
> Application Version:  1.7.0.0
> Application Timestamp:  534d10dd
> Fault Module Name:  StackHash_1d2c
> Fault Module Version:  0.0.0.0
> Fault Module Timestamp:  
> Exception Offset:  
> Exception Code:  c005
> Exception Data:  0008
> OS Version:  6.1.7601.2.1.0.768.3
> Locale ID:  2052
> 
> Is my compilation steps wrong? Thanks.
> 
> BTW, It's OK if qemu-ga.exe run with DLLs.
> 
> 
> 
> Best regards,
> -Gonglei
> 

[Qemu-devel] How to prevent write to partitcular sector of disk

[Shakil k]

I am trying to prevent write from DomU for particular sector of hardisk
which is passed through QEMU device.

I am putting an error condition in ide.c  using API
ide_handle_write_error(s, -ret,  BM_STATUS_ERROR) called from
ide_write_dma_cb, however DomU is still going ahead and writing to those
sectors.
Is there a way to prevent DomU from writing to certain sector of hard disk
as well as propagate those error back to DomU saying, "Write error" or some
message so that user is notified of error writing to certain sectors of
disk.


Regards
Shakil
---

[Qemu-devel] How to prevent DomU(windows) to write to certain sector of hard drive

[Shakil k]

I am trying to prevent write from DomU for particular sector of hardisk
which is passed through QEMU device.

I am putting an error condition in ide.c  using API
ide_handle_write_error(s, -ret,  BM_STATUS_ERROR) called from
ide_write_dma_cb, however DomU is still going ahead and writing to those
sectors.
Is there a way to prevent DomU from writing to certain sector of hard disk
as well as propagate those error back to DomU saying, "Write error" or some
message so that user is notified of error writing to certain sectors of
disk.


Regards
Shakil
---

Re: [Qemu-devel] How to prevent DomU(windows) to write to certain sector of hard drive

[Shakil k]

On Tue, Oct 29, 2013 at 7:51 AM, Shakil k  wrote:

> I am trying to prevent write from DomU for particular sector of hardisk
> which is passed through QEMU device.
>
> I am putting an error condition in ide.c  using API
> ide_handle_write_error(s, -ret,  BM_STATUS_ERROR) called from
> ide_write_dma_cb, however DomU is still going ahead and writing to those
> sectors.
> Is there a way to prevent DomU from writing to certain sector of hard disk
> as well as propagate those error back to DomU saying, "Write error" or some
> message so that user is notified of error writing to certain sectors of
> disk.
>
> I am not sure if my question is lost in heavy traffic, but can anyone
respond as to how to prevent and propagate the error message from QEMU to
DomU(Windows), I can block the write to certain sectors of hard drive, but
not able to send the error message back to Windows. I want DomU users also
to be notified in case of write errors to certain sectors.

>
> Regards
> Shakil
> ---
>

[Qemu-devel] How to deal with the problem about communicating from vm to host or vm to vm when switch process was restarted

[Zhangkun (K)]

Hi, all
  I used switch and vhost-user to receive packets from vm to host, or to send 
packets to vm .
When switch process was restarted by any time, it was not communicated with 
each other from vm to host.
How to deal with the problem about communicating from vm to host or vm to vm 
when switch process was restarted?

Thanks.

Re: [Qemu-devel] [PATCH] support vhost-user socket to reconnect

[Zhangkun (K)]

Yes, this patch is only reconnect socket.
The "Is_reconnect" field is used by next patch. 

-Original Message-
From: Zhang Haoyu [mailto:zhhy.zhangha...@gmail.com] 
Sent: Monday, December 22, 2014 3:20 PM
To: Zhangkun (K); qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] support vhost-user socket to reconnect

Hi, Kun

Is this patch one of patch series?
I don't see any place to reference "is_reconnect" field.

On 2014/12/22 15:06, zhangkun wrote:
> From: zhangkun 
> 
> Signed-off-by: zhangkun 
> ---
>  net/vhost-user.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/net/vhost-user.c b/net/vhost-user.c index 
> 24e050c..957e78c 100644
> --- a/net/vhost-user.c
> +++ b/net/vhost-user.c
> @@ -26,6 +26,7 @@ typedef struct VhostUserChardevProps {
>  bool is_socket;
>  bool is_unix;
>  bool is_server;
> +bool is_reconnect;
>  } VhostUserChardevProps;
>  
>  VHostNetState *vhost_user_get_vhost_net(NetClientState *nc) @@ -132,6 
> +133,11 @@ static void net_vhost_user_event(void *opaque, int event)
>  }
>  }
>  
> +static bool net_vhost_user_can_read(void *opaque) {
> +return true;
> +}
> +
>  static int net_vhost_user_init(NetClientState *peer, const char *device,
> const char *name, CharDriverState *chr,
> bool vhostforce) @@ -151,7 +157,7 @@ 
> static int net_vhost_user_init(NetClientState *peer, const char *device,
>  s->chr = chr;
>  s->vhostforce = vhostforce;
>  
> -qemu_chr_add_handlers(s->chr, NULL, NULL, net_vhost_user_event, s);
> +qemu_chr_add_handlers(s->chr, net_vhost_user_can_read, NULL, 
> + net_vhost_user_event, s);
>  
Why no read handler?

>  return 0;
>  }
> @@ -167,6 +173,8 @@ static int net_vhost_chardev_opts(const char *name, const 
> char *value,
>  props->is_unix = true;
>  } else if (strcmp(name, "server") == 0) {
>  props->is_server = true;
> +} else if (strcmp(name, "reconnect") == 0) {
> +props->is_reconnect = true;
>  } else {
>  error_report("vhost-user does not support a chardev"
>   " with the following option:\n %s = %s",
> 

[Qemu-devel] VHOST-BLK is not working

[Sudheer K]

Hi,

I am experimenting with VHOST-BLK with the codes I got from:
QEMU - git://github.com/asias/qemu.git
KERNEL - git://github.com/asias/linux.git
The VM I am booting is compiled with MSIX config options.

I am seeing a failure in the QEMU function msix_enabled during the
initialization of the block device  While the first expression
(dev->cap_present & QEMU_PCI_CAP_MSIX)   is successful, the second one
(dev->config[dev->msix_cap + MSIX_CONTROL_OFFSET] &
 MSIX_ENABLE_MASK) is failing.

I could not see a msix_init function from hw/block/virtio-blk.c whereas
there is one for VHOST-NET from vmxnet3_init_msix.

I will appreciate if someone could point out what I am missing here.

Thanks and Regards

Sudheer

[Qemu-devel] qemu on linux

[K D]

Hi

This is my first post here. Am not sure if this is right forum. I am
trying to get KVM/qemu running on linux. I compiled 2.6.27.10 by
enabling "KVM", "KVM for intel" options at configure time. My box is
running with KVM enabled inside kernel. I also built
qemu-kvm-0.12.2 using above kernel headers etc. I enabled
virtualization in BIOS. I didn't try to install any guest from CD etc.
I made a hard disk image, installed grub on it, copied kernel, initrd
onto it. Now when I try to create Vm as below, it crashes with
following backtrace. What could be going wrong? Am going thru qemu code to see 
if I can get any hints.

Also when I try
to say "-m 256" malloc (or posix_memalign) fails with ENOMEM. So right
now "-m 128", which is default, works. Why is that? I have 4G RAM in my
setup and my native linux is using less than 1G. I didn't find any command line 
option to raise rlimits for qemu.

Sounds like I'm doing some basic stuff wrong. I'm using bios, vapic, pxe-rtl 
bin straight from the qemu-kvm dir. 

If I don't do '-nographic' its running into some malloc failure inside some vga 
routine. I pasted that backtrace too below.

Appreciate your help.
thanks

Here is my commandline:
qemu-system-x86_64
-hda /dev/shm/vmhd.img -bios ./bios.bin --option-rom ./vapic.bin
-curses -nographic -vga none -option-rom ./pxe-rtl8139.bin

#0  0x414875a6 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x414875a6 in raise () from /lib/libc.so.6
#1  0x4148ad18 in abort () from /lib/libc.so.6
#2  0x080b4cb3 in die2 (err=,
what=0x81f2662 "pthread_create") at posix-aio-compat.c:80
#3  0x080b5682 in thread_create (arg=,
start_routine=, attr=,
thread=) at posix-aio-compat.c:118
#4  spawn_thread () at posix-aio-compat.c:379
#5  qemu_paio_submit (aiocb=0x846b550) at posix-aio-compat.c:390
#6  0x080b57cb in paio_submit (bs=0x843c008, fd=5, sector_num=0,
qiov=0x84cefb8, nb_sectors=512, cb=0x81cb950 ,
opaque=0x84cef80, type=1) at posix-aio-compat.c:584
#7  0x080cc7b8 in raw_aio_submit (type=,
opaque=, cb=,
nb_sectors=, qiov=,
sector_num=, bs=)
at block/raw-posix.c:562
#8  raw_aio_readv (bs=0x843c008, sector_num=0, qiov=0x84cefb8, nb_sectors=1,
cb=0x81cb950 , opaque=0x84cef80) at block/raw-posix.c:570
#9  0x080b0593 in bdrv_aio_readv (bs=0x843c008, sector_num=0, qiov=0x84cefb8,
nb_sectors=1, cb=0x81cb950 , opaque=0x84cef80)
at block.c:1548
#10 0x081cbb26 in dma_bdrv_cb (opaque=0x84cef80, ret=0)
at /ws/pkoya-sjc/temp/qemu-kvm-0.12.2/dma-helpers.c:123
#11 0x081cbcde in dma_bdrv_io (bs=0x843c008, sg=0x846861c, sector_num=0,
cb=0x8074320 , opaque=0x8468f1c, is_write=0)
at /ws/pkoya-sjc/temp/qemu-kvm-0.12.2/dma-helpers.c:167
#12 0x0807441b in ide_read_dma_cb (opaque=0x8468f1c, ret=0)
at /ws/pkoya-sjc/temp/qemu-kvm-0.12.2/hw/ide/core.c:597
#13 0x080760ec in bmdma_cmd_writeb (opaque=0x8468f1c, addr=49152, val=9)
at /ws/pkoya-sjc/temp/qemu-kvm-0.12.2/hw/ide/pci.c:51
#14 0x080d9d5f in ioport_write (data=,
address=, index=) at ioport.c:80
#15 cpu_outb (addr=6587, val=) at ioport.c:198
#16 0xb60a3bc9 in ?? ()
#17 0xc000 in ?? ()
#18 0x0009 in ?? ()
#19 0x in ?? ()
(gdb) q

backtrace without "-nographic"

(gdb) bt
#0  0x414875a6 in raise () from /lib/libc.so.6
#1  0x4148ad18 in abort () from /lib/libc.so.6
#2  0x080b4c3c in qemu_memalign (alignment=4096, size=16777216) at osdep.c:96
#3  0x080b4c5a in qemu_vmalloc (size=16777216) at osdep.c:110
#4  0x08119995 in qemu_ram_alloc (size=16777216)
at /devel/temp/qemu-kvm-0.12.2/exec.c:2550
#5  0x0807ffd0 in vga_common_init (s=0x84be7e4, vga_ram_size=16777216)
at /devel/temp/qemu-kvm-0.12.2/hw/vga.c:2291
#6  0x080a1c4b in pci_cirrus_vga_initfn (dev=0x84be618)
at /devel/temp/qemu-kvm-0.12.2/hw/cirrus_vga.c:3209
#7  0x0805e61e in pci_qdev_init (qdev=0x84be618, base=0x8229700)
at /devel/temp/qemu-kvm-0.12.2/hw/pci.c:1482
#8  0x080fa7ee in qdev_init (dev=0x84be618)
at /devel/temp/qemu-kvm-0.12.2/hw/qdev.c:242
#9  0x080fa885 in qdev_init_nofail (dev=0x84be618)
at /devel/temp/qemu-kvm-0.12.2/hw/qdev.c:285
#10 0x0805d8ca in pci_create_simple (bus=0x845ab58, devfn=-1,
name=0x81ce0f8 "cirrus-vga")
at /devel/temp/qemu-kvm-0.12.2/hw/pci.c:1533
#11 0x080a2c71 in pci_cirrus_vga_init (bus=0x845ab58)
at /devel/temp/qemu-kvm-0.12.2/hw/cirrus_vga.c:3235
#12 0x0808abc3 in pc_init1 (ram_size=,
boot_device=0xbf9fea17 "cad", kernel_filename=0x0,
kernel_cmdline=0x81f82f8 "", initrd_filename=0x0,
cpu_model=0x81eca10 "qemu64", pci_enabled=1)
at /devel/temp/qemu-kvm-0.12.2/hw/pc.c:1149
#13 0x080518db in main (argc=8, argv=0xbf9feaf4, envp=Cannot access memory at 
address 0x7730
)
at /devel/temp/qemu-kvm-0.12.2/vl.c:6055
(gdb) q


  

[Qemu-devel] VGA blank mode

[K D]

Hi

I'm trying to run kvm/qemu on a linux host built from scratch ie., no x 
windows, no window manager etc. bare minimum libraries etc. when i try to spawn 
a VM with "-curses", I see "VGA Blank Mode" and nothing else. i'm attached to 
serial console for this host. what could be the issue?

thanks

 






From: Segher Boessenkool 
To: Blue Swirl 
Cc: Alexander Graf ; qemu-devel@nongnu.org
Sent: Sun, May 2, 2010 7:19:13 AM
Subject: Re: [Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for 
MPC603 and e300

>>  Your code can change MSR[IP]; there is also a strapping pin that is
>>  sampled on HRESET (and copied to MSR[IP]).
>
> Wouldn't this mean that when the reset is issued by hardware, MSR[IP]
> is always 1 (to boot from ROM) but with software reset it can take
> software defined values?

Yes, that is what it means.

> I think now QEMU ignores MSR[IP].

Fix it :-)


Segher


  

[Qemu-devel] Problem with QEMU / KVM

[K D]

Hi

I built 2.6.27.10 kernel with KVM configured as built-in.

CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=y
CONFIG_KVM_INTEL=y

I built qemu-kvm 0.12.2 from sources pointing to above kernel. When I spawn a 
VM, it hangs at boot. Pl see below. I copied qemu-kvm binary and bios, vga etc 
binaries. I installed grub on a manually created img file. This image has 
nothing but grub, its stage1,1_5,stage2, my kernel and initrd files.

Am spawning VM as below:

qemu-system-x86_64 -hda vmhd.img -L . -curses -show-cursor

grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83

grub> kernel /boot/vmos root=/dev/ram0 ramdisk_size=32768 rw single
   [Linux-bzImage, setup=0x1800, size=0x1cb9b0]

grub> initrd /boot/initrdfs.gz
   [Linux-initrd @ 0x6751000, 0x189b587 bytes]

grub> boot



I copied all these binaries from my dev host to this linux box.
 
-rw-r--r-- 1 root root 131072 May  2 21:31 bios.bin
-rw-r--r-- 1 root root   1025 May  2 21:31 linuxboot.bin
-rw-r--r-- 1 root root   1024 May  2 21:31 multiboot.bin
-rw-r--r-- 1 root root 524288 May  2 21:31 ppc_rom.bin
-rw-r--r-- 1 root root  72192 May  2 21:31 pxe-e1000.bin
-rw-r--r-- 1 root root  56832 May  2 21:31 pxe-i82559er.bin
-rw-r--r-- 1 root root  56320 May  2 21:31 pxe-ne2k_pci.bin
-rw-r--r-- 1 root root  56832 May  2 21:31 pxe-pcnet.bin
-rw-r--r-- 1 root root  56320 May  2 21:31 pxe-rtl8139.bin
-rw-r--r-- 1 root root  56320 May  2 21:31 pxe-virtio.bin
-rwxr-xr-x 1 root root   8960 May  2 21:31 vapic.bin
-rw-r--r-- 1 root root  35840 May  2 21:31 vgabios-cirrus.bin
-rw-r--r-- 1 root root  39936 May  2 21:31 vgabios.bin



Appreciate your help.




From: Anthony Liguori 
To: Gerhard Wiesinger 
Cc: qemu-devel@nongnu.org; Gerd Hoffmann 
Sent: Tue, May 4, 2010 6:32:50 AM
Subject: Re: [Qemu-devel] Problem with QEMU on KVM

On 05/04/2010 12:09 AM, Gerhard Wiesinger wrote:
> On Sat, 24 Apr 2010, Gerhard Wiesinger wrote:
>>> Guess problems comes from the following commit (not yet verified):
>>> commit 37c34d9d5d87ea9d51760310c8863b82cb8c055a
>>> Author: Anthony Liguori 
>>> Date:   Wed Mar 10 09:38:29 2010 -0600
>>> 
>>>input: make vnc use mouse mode notifiers
>>> 
>>>When we switch to absolute mode, we send out a notification (if the 
>>> client
>>>supports it).  Today, we only send this notification when the client 
>>> sends us
>>>a mouse event and we're in the wrong mode.
>>> 
>>>Signed-off-by: Anthony Liguori 
>> 
>> 
>> Ok, verified:
>> git revert -n 37c34d9d5d87ea9d51760310c8863b82cb8c055a
>> => works well.
> 
> Still got no feedback and saw no further changes to fix this problem.

Fix is on the list.

Regards,

Anthony Liguori

> Thnx.
> 
> Ciao,
> Gerhard
> 
> -- http://www.wiesinger.com/
> 


  

[Qemu-devel] qemu usage

[K D]

Hi

I am able to boot my custom kernel off of bare hardware, but when I try to boot 
this with qemu it hangs after first two lines of print about BIOS. i tried 
booting through qemu image and also via '-kernel' arg. same result in both 
cases. i verified that with same qeumu-system-x86_64 i could boot ubuntu 
kernel/initrd in qemu image and also with -kernel arg but not my kernel.

i'm using pc-bios dir as is with all its subdirs and using it as "-L 
path_to_pc-bios". can someone help me understand what could be going on. 

 appreciate your help.
kd






From: Anthony Liguori 
To: Alexander Graf 
Cc: qemu-devel@nongnu.org; Paul Brook ; Julian Pidancet 
; Gerd Hoffmann 
Sent: Mon, May 17, 2010 3:46:14 PM
Subject: Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver

On 05/17/2010 05:26 PM, Alexander Graf wrote:
> I'm trying to think of a project where the clean separation between multiple 
> video outputs implemented in the backend and a separate frontend worked out. 
> So far the only case that has a strikingly similar architecture coming to my 
> mind is mplayer. And I wouldn't call mplayer's GUI story a huge success.
> 
> In fact, couldn't we rather keep all graphic output out of qemu and just 
> expose VNC, possibly with self-made additions to the protocol to speed up 
> local rendering (thinking an SHM extension here)?

I think the whole reason this has failed is that if the GUI is a separate 
project, the path of least resistance is to use existing interfaces instead of 
inventing new ones.  That means these GUIs tend to be restricted by whatever 
management interface exists which isn't actually good enough.

You really need to have the GUI as part of the main project such that when it 
needs a new interface, it can be added very easily.

>   Then we could still offer a separate SDL based viewer that could do the 
> same things it does now. But we'd also open up the gate for a whole new 
> integration level with possible GUIs.
>

You could, but I think it introduces more complexity which just is going to get 
in the way of building a good GUI.

Regards,

Anthony Liguori

> Alex
> 
>


  

[Qemu-devel] qemu does not wait for gdb

[Pawel K]

Hello

I'm trying to connect gdb to qemu and it seems not to
work correctly.
I mean it does not wait for gdb to connect.
I perform the following command to do that:

qemu -s -kernel arch/i386/boot/bzImage -hda
root-2.4.20.img -append "root=/dev/hda"

It just runs like this option hasn't been specified.
No error message is displayed.

I use qemu.0.9.0 under linux.

Do You know what can be wrong.

PS: sorry for posting to development mailing list but
I cannot subscribe to "Qemu for Linux". I receive the
"Hacking attempt" message when clicking the register
button. Where can I report problem with subscription ?

Thank You for help

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Qemu-devel] monitor's memory dump

[Pawel K]

Hello
Look at the following monitor's memory dump commands:

(qemu) x/1xw 0
: 0xb7d00694

(qemu) x/1xw 1
0001: 0xb7d00694

(qemu) x/2xw 0
: 0xb7d00694 0x081459a6

It looks like the single 4-byte dumps always show the
first memory location.

Is it a bug ?

I use qemu-0.9.0 under linux.
I run the qemu with the pure bzImage 2.6.23 from
kernel.org.

qemu -kernel bzImage ...

Thank You for help.

PS: sorry for posting to devel mailing list but I
cannot subscribe to the "Qemu for Linux" mailing list.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[PATCH] ui/gtk: Ignore 2- and 3-button press events

[K. Lange]

GTK already produces corresponding GDK_BUTTON_PRESS events
alongside 2BUTTON and 3BUTTON_PRESS events. The 2BUTTON and
3BUTTON_PRESS events were incorrectly being interpreted and
passed to guests as button release events.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/558
Signed-off-by: K. Lange 
---
 ui/gtk.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/ui/gtk.c b/ui/gtk.c
index a8567b9ddc..8675ae76fa 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -958,6 +958,10 @@ static gboolean gd_button_event(GtkWidget *widget, 
GdkEventButton *button,
 return TRUE;
 }
 
+if (button->type == GDK_2BUTTON_PRESS || button->type == 
GDK_3BUTTON_PRESS) {
+return TRUE;
+}
+
 qemu_input_queue_btn(vc->gfx.dcl.con, btn,
  button->type == GDK_BUTTON_PRESS);
 qemu_input_event_sync();
-- 
2.25.1

[Qemu-devel] Baremetal Netduino2 -- cannot output on UARTs 2-4

[Seth K]

I have made a bare metal "Hello World" program for the Netduino2. I have
pushed it here:

https://github.com/skintigh/baremetal_netduino2

It should output "Test 1/4" to USART 1, "Test 2/4" to USART 2, "Test 3/4"
to USART 3 and "Test 4/4" to UART 4.

What actually happens in QEMU is only the first string is output. That may
be a command line argument error on my part, so for a sanity check I put
printf statements in the function stm32f2xx_usart_write in
qemu/hw/char/stm32f2xx_usart.c and recompiled qemu. The result is text sent
to UART1 and UART4 make is to the function (though only 1 is output), while
writes to 2 and 3 simply disappear and never make it to that function. I
assumed all writes to UARTs would go to that function.

Am I doing something dumb? Is this a bug? Any help would be greatly
appreciated.

Thanks,
Seth

Re: [Qemu-devel] Baremetal Netduino2 -- cannot output on UARTs 2-4

[Seth K]

You're right, qemu was not happy with that command line, but your pointer
really helped me out, thank you!! I think a combination of my
misunderstanding what the arguments meant, and a weird bug with this chip,
resulted in my complete confusion.

Using the command line:
../qemu/arm-softmmu/qemu-system-arm -M netduino2 -nographic -kernel
output.bin -serial unix:///tmp/uart1,server -serial
unix:///tmp/uart2,server -serial unix:///tmp/uart3,server -serial
unix:///tmp/uart4,server

and opening 4 sockets:
socat - UNIX-CONNECT:/tmp/uart1 ...

sends data written to UART1 to /tmp/uart1 and UART4 to /tmp/uart4. 2 and 3
still disappear but that seems to be a bug and I have reported it. Now to
test this on a chip with 8 UARTS...

Thanks again!

On Wed, Oct 5, 2016 at 5:21 PM, Alistair Francis 
wrote:

> On Wed, Oct 5, 2016 at 10:45 AM, Seth K  wrote:
> > Thanks for that link.
> >
> > I tried that command line and it output UART4 but UART 1 disappeared and
> > UART2-3 are still missing. That page doesn't seem to have an explanation
> of
> > what that command line is doing nor why /dev/null is used twice, so I'm a
> > little lost. Removing the first /dev/null made UART4 disappear but UART1
> > came back. In the past I've looked for documentation that explained the
> > command line but everything I found was very vague.
>
> Hey Seth,
>
> Each -serial option is used to specify where to send the serial
> output. These are parsed in order when passed into QEMU. So the first
> -serial option controls where to send UART0 data and so on.
>
> That example I sent you is for a Netduino 2 so you will need to
> changed the -serial options to match what you want to print, but it is
> a good example you can use. Especially for muxing multiple serial
> devices.
>
> It sounds like you want something like:
> -chardev stdio,mux=on,id=terminal -serial chardev:terminal -serial
> chardev:terminal -serial chardev:terminal -serial chardev:terminal
> -monitor chardev:terminal
>
> Which will output everything to the terminal. I can image that will
> cause some problems though, so you might want to output some to
> telnet/sockets instead to stop everything being mixed together.
>
> Remember that -chardev creates the output device but doesn't connect
> it to a UART. You need the -serial option to do that.
>
> Thanks,
>
> Alistair
>
> >
> > build.sh has a bunch of command lines I've found online and tried:
> >
> > $QEMU/arm-softmmu/qemu-system-arm -M netduino2 -nographic -kernel
> output.bin
> >
> >
> > #this one sends UART1 to a socket but not UART2
> > #../qemu/arm-softmmu/qemu-system-arm -M netduino2 -m 128M -nographic
> -kernel
> > output.bin -serial unix:///tmp/uart,server -serial
> unix:///tmp/uart2,server
> > #socat - UNIX-CONNECT:/tmp/uart
> >
> > #../../qemu/arm-softmmu/qemu-system-arm -M netduino2 -m 128M -nographic
> > -kernel output.bin -serial unix:///tmp/uart1,server,id=uart2 -serial
> > unix:///tmp/uart2,server,id=uart1
> > #didn't redirect
> >
> > #other desperation
> > #../qemu/arm-softmmu/qemu-system-arm -M netduino2 -m 128M -nographic -s
> -d
> > cpu,in_asm -kernel output.bin
> > #../qemu/arm-softmmu/qemu-system-arm -M netduino2 -m 128M -nographic
> -serial
> > unix:///tmp/uart,server -kernel output.bin
> > #../qemu/arm-softmmu/qemu-system-arm -M netduino2 -m 128M -nographic
> > -chardev socket,id=usar0,host=localhost,port=31337,server -kernel
> output.bin
> > #../qemu/arm-softmmu/qemu-system-arm -M netduino2 -m 128M -nographic
> > -chardev socket,id=chardev,host=localhost,port=31337,server -kernel
> > output.bin
> > #../../qemu/arm-softmmu/qemu-system-arm -M netduino2 -m 128M -nographic
> > -kernel output.bin -s -S
> >
> > On Tue, Oct 4, 2016 at 12:59 PM, Alistair Francis 
> > wrote:
> >>
> >> On Mon, Oct 3, 2016 at 1:25 PM, Seth K  wrote:
> >> > I have made a bare metal "Hello World" program for the Netduino2. I
> have
> >> > pushed it here:
> >> >
> >> > https://github.com/skintigh/baremetal_netduino2
> >> >
> >> > It should output "Test 1/4" to USART 1, "Test 2/4" to USART 2, "Test
> >> > 3/4"
> >> > to USART 3 and "Test 4/4" to UART 4.
> >> >
> >> > What actually happens in QEMU is only the first string is output. That
> >> > may
> >> > be a command line argument error on my part, so for a sanity check I
> put
> >> > printf statements in the function stm32f2xx_usart_write in
> >> > qemu/hw/char/stm32f2xx_usart.c 

Re: [Qemu-devel] [Bug 1630723] [NEW] UART writes to netduino2/stm32f205-soc disappear

[Seth K]

The only machine I saw listed in the help output is "netduino2." I pulled
QEMU from github, was that the right thing to do?

I found the specifications for the stm32f2xx and some similar chips and
verified the addresses and interrupts are correct.

The stm32f205 should support 6 UARTs, and the 6 addresses and IRQs are
coded correctly. However there is a hard-coded value MAX_SERIAL_PORTS limiting
serial_hds to 4, and I don't know why. I am considering submitting a patch.

If I increase MAX_SERIAL_PORTS I can write to UARTs 1, 4, 5, and 6 and
output them to sockets. However writes to UARTs 2 and 3 just disappear.
They don't even trigger my printf in stm32f2xx_usart_write. It seems like
they are being intercepted somewhere, and unfortunately my knowledge of
QEMU is too low to know where to look. Any pointers would be greatly
appreciated.

Thanks again for all your help

On Thu, Oct 6, 2016 at 8:18 PM, Alistair Francis 
wrote:

> QEMU only supports the Netduino (not Netduino 2) it is possible that
> the base addresses are different and that is why you aren't seeing the
> serial output.
>
> Thanks,
>
> Alistair
>
>
> On Wed, Oct 5, 2016 at 11:56 AM, Seth  wrote:
> > Public bug reported:
> >
> > Writes to UART 2 and 3 disappear. As a sanity check I put printf
> > statements in the function stm32f2xx_usart_write in
> > qemu/hw/char/stm32f2xx_usart.c and recompiled qemu. The result confirmed
> > text sent to UART1 and UART4 are sent to that function while text sent
> > to UART 2 and 3 are not. I assume writes to all 4 need to make it to
> > that function for emulations to operate correctly.
> >
> > Example code that writes to all 4 UARTs/USARTs (does not contain the
> printf statements mention above):
> > https://github.com/skintigh/baremetal_netduino2
> >
> > ** 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/1630723
> >
> > Title:
> >   UART writes to netduino2/stm32f205-soc disappear
> >
> > Status in QEMU:
> >   New
> >
> > Bug description:
> >   Writes to UART 2 and 3 disappear. As a sanity check I put printf
> >   statements in the function stm32f2xx_usart_write in
> >   qemu/hw/char/stm32f2xx_usart.c and recompiled qemu. The result
> >   confirmed text sent to UART1 and UART4 are sent to that function while
> >   text sent to UART 2 and 3 are not. I assume writes to all 4 need to
> >   make it to that function for emulations to operate correctly.
> >
> >   Example code that writes to all 4 UARTs/USARTs (does not contain the
> printf statements mention above):
> >   https://github.com/skintigh/baremetal_netduino2
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/qemu/+bug/1630723/+subscriptions
> >
>

Re: [Qemu-devel] [Bug 1630723] [NEW] UART writes to netduino2/stm32f205-soc disappear

[Seth K]

I applied that patch, made qemu and ran my code, I didn't see a change.

According to the STM32F20xxx memory map, the memory range seems to be 0x400
-- UART 1 is listed as 0x4001 - 0x400103FF. Should that memory region
be set to 0x400?

I tried that too, no change yet, but maybe I should look at the other
memory settings.

I also tried making these changes in another branch where I made this chip
have 8 UARTS. That was unchanged: I can only output UARTS 1,4,5,6.

On Fri, Oct 7, 2016 at 12:10 PM, Alistair Francis 
wrote:

> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis 
> wrote:
> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K  wrote:
> >> The only machine I saw listed in the help output is "netduino2." I
> pulled
> >> QEMU from github, was that the right thing to do?
> >>
> >> I found the specifications for the stm32f2xx and some similar chips and
> >> verified the addresses and interrupts are correct.
> >
> > Sorry my mistake. It is a the Netduino 2 Plus that we don't support.
> >
> > I think we should move this conversation to the bug report as well, I
> > was hoping that replying to the email would update the bug report but
> > it doesn't look like it.
> >
> >>
> >> The stm32f205 should support 6 UARTs, and the 6 addresses and IRQs are
> coded
> >> correctly. However there is a hard-coded value MAX_SERIAL_PORTS limiting
> >> serial_hds to 4, and I don't know why. I am considering submitting a
> patch.
> >
> > I'm not sure why we have that limit, you can submit a patch and see
> > what everyone says.
> >
> >>
> >> If I increase MAX_SERIAL_PORTS I can write to UARTs 1, 4, 5, and 6 and
> >> output them to sockets. However writes to UARTs 2 and 3 just disappear.
> They
> >> don't even trigger my printf in stm32f2xx_usart_write. It seems like
> they
> >> are being intercepted somewhere, and unfortunately my knowledge of QEMU
> is
> >> too low to know where to look. Any pointers would be greatly
> appreciated.
> >
> > Strange. There could be something else addressed there. If you run
> > 'info mtree' at the QEMU prompt (Ctrl-a + c) you should be able to see
> > the memory map of the system.
>
> Hey Seth,
>
> What if you try this diff? Does that help?
>
> diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c
> index 4c6640d..b07c67b 100644
> --- a/hw/char/stm32f2xx_usart.c
> +++ b/hw/char/stm32f2xx_usart.c
> @@ -204,7 +204,7 @@ static void stm32f2xx_usart_init(Object *obj)
>  sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq);
>
>  memory_region_init_io(&s->mmio, obj, &stm32f2xx_usart_ops, s,
> -  TYPE_STM32F2XX_USART, 0x2000);
> +  TYPE_STM32F2XX_USART, 0x200);
>  sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
>  }
>
> Thanks,
>
> Alistair
>

Re: [Qemu-devel] [Bug 1630723] [NEW] UART writes to netduino2/stm32f205-soc disappear

[Seth K]

It's a bare metal program so I don't really have anywhere to print to,
other than my custom function to output to the uart. I did double check all
the address to make sure they agreed with the documentation and the Qemu
source code. I tried changing around the destinations of the output just to
verify the order of the write or the destination somehow affected the
output. I tried being tricky, like instead of writing to usart 3 I wrote to
uart 4 - 0x400 (the same address, it didn't work). The code should be
simple enough that I don't have room for any crazy mistakes:

volatile unsigned char * const USART1_PTR = (unsigned char *)0x40011000;
volatile unsigned char * const USART2_PTR = (unsigned char *)0x40004400;
volatile unsigned char * const USART3_PTR = (unsigned char *)0x40004800;
volatile unsigned char * const UART4_PTR = (unsigned char *)0x40004c00;

void display(const char *string, volatile unsigned char * uart_addr){
  while(*string != '\0'){
*(uart_addr+4) = *string;
string++;
  }
}

int my_init(){
  display("Test 1/4\n", USART1_PTR);
  display("Test 2/4\n", USART2_PTR);
  display("Test 3/4\n", USART3_PTR);
  display("Test 4/4\n", UART4_PTR);
}


In the past I ran a really long test where I wrote to every possible
address just to see what happens. No unexpected output occurred. I can do
that test again, but it takes hours. I could also write code to convert the
address to something printable to verify the address isn't being changed,
but that seems unlikely.

Another thought I had is maybe there is some sort of interaction between
where I am setting the stack top - 0x20001000 - but that doesn't seem like
it should interfere. Maybe the linker or objcopy are doing something crazy?

I don't understand Qemu enough to know what should be calling the functions
that handle UART read/write. Is there something I should look at in Qemu
and try to intercept?

On Fri, Oct 7, 2016 at 6:27 PM, Alistair Francis 
wrote:

> On Fri, Oct 7, 2016 at 1:04 PM, Seth K  wrote:
> > I applied that patch, made qemu and ran my code, I didn't see a change.
> >
> > According to the STM32F20xxx memory map, the memory range seems to be
> 0x400
> > -- UART 1 is listed as 0x4001 - 0x400103FF. Should that memory
> region be
> > set to 0x400?
>
> I was hoping that would have fixed it.
>
> It sounds like it should be 0x400 then, although it doesn't sound like
> this is causing this issue.
>
> >
> > I tried that too, no change yet, but maybe I should look at the other
> memory
> > settings.
>
> Maybe, it is very strange that it's not reaching the read/write functions.
>
> Can you try putting print statements in the guest software to make
> sure it is writing to the locations you expect and then make sure
> there are no conditionals in QEMU that cause the print statements to
> not be printed. See what that uncovers.
>
> Thanks,
>
> Alistair
>
> >
> > I also tried making these changes in another branch where I made this
> chip
> > have 8 UARTS. That was unchanged: I can only output UARTS 1,4,5,6.
> >
> > On Fri, Oct 7, 2016 at 12:10 PM, Alistair Francis 
> > wrote:
> >>
> >> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis 
> >> wrote:
> >> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K  wrote:
> >> >> The only machine I saw listed in the help output is "netduino2." I
> >> >> pulled
> >> >> QEMU from github, was that the right thing to do?
> >> >>
> >> >> I found the specifications for the stm32f2xx and some similar chips
> and
> >> >> verified the addresses and interrupts are correct.
> >> >
> >> > Sorry my mistake. It is a the Netduino 2 Plus that we don't support.
> >> >
> >> > I think we should move this conversation to the bug report as well, I
> >> > was hoping that replying to the email would update the bug report but
> >> > it doesn't look like it.
> >> >
> >> >>
> >> >> The stm32f205 should support 6 UARTs, and the 6 addresses and IRQs
> are
> >> >> coded
> >> >> correctly. However there is a hard-coded value MAX_SERIAL_PORTS
> >> >> limiting
> >> >> serial_hds to 4, and I don't know why. I am considering submitting a
> >> >> patch.
> >> >
> >> > I'm not sure why we have that limit, you can submit a patch and see
> >> > what everyone says.
> >> >
> >> >>
> >> >> If I increase MAX_SERIAL_PORTS I can write to UARTs 1, 4, 5, and 6
> and
> &g

Re: [Qemu-devel] [Bug 1630723] [NEW] UART writes to netduino2/stm32f205-soc disappear

[Seth K]

I've narrowed this down. In exec.c the address is reduced by
section->offset_within_address_space. However, half the time that seems to
be wrong.

For usart1 at 40011004 it is 40011000, a difference of 4 which signals a
usart write.

For usart2 at 40004404 it is 4c00, a difference of 3804 which means
nothing.

On Wed, Oct 12, 2016 at 6:25 PM, Seth K  wrote:

> It's a bare metal program so I don't really have anywhere to print to,
> other than my custom function to output to the uart. I did double check all
> the address to make sure they agreed with the documentation and the Qemu
> source code. I tried changing around the destinations of the output just to
> verify the order of the write or the destination somehow affected the
> output. I tried being tricky, like instead of writing to usart 3 I wrote to
> uart 4 - 0x400 (the same address, it didn't work). The code should be
> simple enough that I don't have room for any crazy mistakes:
>
> volatile unsigned char * const USART1_PTR = (unsigned char *)0x40011000;
> volatile unsigned char * const USART2_PTR = (unsigned char *)0x40004400;
> volatile unsigned char * const USART3_PTR = (unsigned char *)0x40004800;
> volatile unsigned char * const UART4_PTR = (unsigned char *)0x40004c00;
>
> void display(const char *string, volatile unsigned char * uart_addr){
>   while(*string != '\0'){
> *(uart_addr+4) = *string;
> string++;
>   }
> }
>
> int my_init(){
>   display("Test 1/4\n", USART1_PTR);
>   display("Test 2/4\n", USART2_PTR);
>   display("Test 3/4\n", USART3_PTR);
>   display("Test 4/4\n", UART4_PTR);
> }
>
>
> In the past I ran a really long test where I wrote to every possible
> address just to see what happens. No unexpected output occurred. I can do
> that test again, but it takes hours. I could also write code to convert the
> address to something printable to verify the address isn't being changed,
> but that seems unlikely.
>
> Another thought I had is maybe there is some sort of interaction between
> where I am setting the stack top - 0x20001000 - but that doesn't seem like
> it should interfere. Maybe the linker or objcopy are doing something crazy?
>
> I don't understand Qemu enough to know what should be calling the
> functions that handle UART read/write. Is there something I should look at
> in Qemu and try to intercept?
>
> On Fri, Oct 7, 2016 at 6:27 PM, Alistair Francis 
> wrote:
>
>> On Fri, Oct 7, 2016 at 1:04 PM, Seth K  wrote:
>> > I applied that patch, made qemu and ran my code, I didn't see a change.
>> >
>> > According to the STM32F20xxx memory map, the memory range seems to be
>> 0x400
>> > -- UART 1 is listed as 0x4001 - 0x400103FF. Should that memory
>> region be
>> > set to 0x400?
>>
>> I was hoping that would have fixed it.
>>
>> It sounds like it should be 0x400 then, although it doesn't sound like
>> this is causing this issue.
>>
>> >
>> > I tried that too, no change yet, but maybe I should look at the other
>> memory
>> > settings.
>>
>> Maybe, it is very strange that it's not reaching the read/write functions.
>>
>> Can you try putting print statements in the guest software to make
>> sure it is writing to the locations you expect and then make sure
>> there are no conditionals in QEMU that cause the print statements to
>> not be printed. See what that uncovers.
>>
>> Thanks,
>>
>> Alistair
>>
>> >
>> > I also tried making these changes in another branch where I made this
>> chip
>> > have 8 UARTS. That was unchanged: I can only output UARTS 1,4,5,6.
>> >
>> > On Fri, Oct 7, 2016 at 12:10 PM, Alistair Francis > >
>> > wrote:
>> >>
>> >> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis > >
>> >> wrote:
>> >> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K  wrote:
>> >> >> The only machine I saw listed in the help output is "netduino2." I
>> >> >> pulled
>> >> >> QEMU from github, was that the right thing to do?
>> >> >>
>> >> >> I found the specifications for the stm32f2xx and some similar chips
>> and
>> >> >> verified the addresses and interrupts are correct.
>> >> >
>> >> > Sorry my mistake. It is a the Netduino 2 Plus that we don't support.
>> >> >
>> >> > I think we should move this conversation to the bug report as well, I
>> >> > was hoping th

[Qemu-devel] [PATCH] Video and sound capture to a videofile through ffmpeg

[Alex K]

Hello everyone,

I've made a patch that adds ability to record video of what's going on
inside qemu. It uses ffmpeg libraries. Basically, the patch adds
2 new commands to the console:
capture_start path framerate
capture_stop

path is required
framerate could be 24, 25, 30 or 60. Default is 60
video codec is always h264

The patch uses ffmpeg so you will need to install these packages:
ffmpeg libavformat-dev libavcodec-dev libavutil-dev libswscale-dev

This is my first time posting here, so please correct me if I'm doing
something wrong

Signed-off-by: Alex K 
---
 configure  |  20 +
 default-configs/i386-softmmu.mak   |   1 +
 default-configs/x86_64-softmmu.mak |   1 +
 hmp-commands.hx|  34 ++
 hmp.h  |   2 +
 hw/display/Makefile.objs   |   2 +
 hw/display/capture.c   | 761 +
 hw/display/capture.h   |  78 
 8 files changed, 899 insertions(+)
 create mode 100644 hw/display/capture.c
 create mode 100644 hw/display/capture.h

diff --git a/configure b/configure
index 6db3044..0b927f8 100755
--- a/configure
+++ b/configure
@@ -281,6 +281,7 @@ opengl=""
 opengl_dmabuf="no"
 avx2_opt="no"
 zlib="yes"
+libav="yes"
 lzo=""
 snappy=""
 bzip2=""
@@ -1987,6 +1988,25 @@ if test "$seccomp" != "no" ; then
 seccomp="no"
 fi
 fi
+#
+# libav check
+
+if test "$libav" != "no" ; then
+cat > $TMPC << EOF
+#include 
+#include 
+
+int main(void){ av_register_all(); avcodec_register_all(); return 0; }
+EOF
+if compile_prog "" "-lm -lpthread -lavformat -lavcodec -lavutil -lswscale 
-lswresample" ; then
+:
+else
+error_exit "libav check failed" \
+"Make sure to have the libav libs and headers installed."
+fi
+fi
+LIBS="$LIBS -lm -lpthread -lavformat -lavcodec -lavutil -lswscale -lswresample"
+
 ##
 # xen probe
 
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 029e952..a24ac7c 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -60,3 +60,4 @@ CONFIG_SMBIOS=y
 CONFIG_HYPERV_TESTDEV=$(CONFIG_KVM)
 CONFIG_PXB=y
 CONFIG_ACPI_VMGENID=y
+CONFIG_CAPTURE=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index d1d7432..9919e93 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -60,3 +60,4 @@ CONFIG_SMBIOS=y
 CONFIG_HYPERV_TESTDEV=$(CONFIG_KVM)
 CONFIG_PXB=y
 CONFIG_ACPI_VMGENID=y
+CONFIG_CAPTURE=y
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 8819281..2c708ae 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1777,3 +1777,37 @@ ETEXI
 STEXI
 @end table
 ETEXI
+
+{
+.name   = "capture_start",
+.args_type  = "filename:F,fps:i?",
+.params = "filename [framerate]",
+.help   = "Start video capture",
+.cmd= hmp_capture_start,
+},
+
+STEXI
+@item capture_start @var{filename} [@var{framerate}]
+@findex capture_start
+Start video capture.
+Capture video into @var{filename} with framerate @var{framerate}.
+
+Defaults:
+@itemize @minus
+@item framerate = 60
+@end itemize
+ETEXI
+
+{
+.name   = "capture_stop",
+.args_type  = "",
+.params = "",
+.help   = "Stop video capture",
+.cmd= hmp_capture_stop,
+},
+
+STEXI
+@item capture_stop
+@findex capture_stop
+Stop video capture.
+ETEXI
diff --git a/hmp.h b/hmp.h
index 799fd37..36c7a4d 100644
--- a/hmp.h
+++ b/hmp.h
@@ -138,5 +138,7 @@ void hmp_rocker_of_dpa_groups(Monitor *mon, const QDict 
*qdict);
 void hmp_info_dump(Monitor *mon, const QDict *qdict);
 void hmp_hotpluggable_cpus(Monitor *mon, const QDict *qdict);
 void hmp_info_vm_generation_id(Monitor *mon, const QDict *qdict);
+void hmp_capture_start(Monitor *mon, const QDict *qdict);
+void hmp_capture_stop(Monitor *mon, const QDict *qdict);
 
 #endif
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 551c050..a918896 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -20,6 +20,8 @@ common-obj-$(CONFIG_ZAURUS) += tc6393xb.o
 
 common-obj-$(CONFIG_MILKYMIST_TMU2) += milkymist-tmu2.o
 
+obj-$(CONFIG_CAPTURE) += capture.o
+
 obj-$(CONFIG_OMAP) += omap_dss.o
 obj-$(CONFIG_OMAP) += omap_lcdc.o
 obj-$(CONFIG_PXA2XX) += pxa2xx_lcd.o
diff --git a/hw/display/capture.c b/hw/display/capture.c
new file mode 100644
index 000..c89aaa0
--- /dev/null
+++ b/hw/display/capture.c
@@ -0,0 +1,761 @@
+#include "capture.h"
+
+static void sound_capture_notify(void *opaque

[Qemu-devel] possible bug hw/adc/stm32f2xx_adc.c

[Seth K]

Thank you all for help with my last patch. I found one more entry in my
notes that could be a bug, or could be a misunderstanding on my part.

The memory map in DocID15818 (Rev 15) datasheet says:
ADC1 - ADC2 - ADC3:  0x40012000-0x400123FF

That suggests a size of 0x400 (they share that range?)

Line 279/280 of hw/adc/stm32f2xx_adc.c seems to use 0xFF
memory_region_init_io(&s->mmio, obj, &stm32f2xx_adc_ops, s,
TYPE_STM32F2XX_ADC, 0xFF); Probably just confusion on my part, but thought
I would mention it just in case.
Thanks,
Seth

PS: Sorry if you are all the wrong people to email about this ADC...

[Qemu-devel] [PATCH] Corrected memory regions

[Seth K]

I corrected these 2 memory regions based on specifications from the chip
manufacturer. The existing ranges seem to overlap and and cause odd
behavior and/or crashes when trying to set up multiple UARTs,
I also played with changing MAX_SERIAL_PORTS to 8 to match the hardware,
but I did not include that in this patch as I never fully tested its
effects.
This is my first patch, I hope I did it correctly,
Seth Kintigh
---
 hw/char/stm32f2xx_usart.c  | 2 +-
 hw/timer/stm32f2xx_timer.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c
index 032b5fda13..f3363a2952 100644
--- a/hw/char/stm32f2xx_usart.c
+++ b/hw/char/stm32f2xx_usart.c
@@ -202,7 +202,7 @@ static void stm32f2xx_usart_init(Object *obj)
 sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq);

 memory_region_init_io(&s->mmio, obj, &stm32f2xx_usart_ops, s,
-  TYPE_STM32F2XX_USART, 0x2000);
+  TYPE_STM32F2XX_USART, 0x400);
 sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
 }

diff --git a/hw/timer/stm32f2xx_timer.c b/hw/timer/stm32f2xx_timer.c
index 58fc7b1188..ae744d1642 100644
--- a/hw/timer/stm32f2xx_timer.c
+++ b/hw/timer/stm32f2xx_timer.c
@@ -308,7 +308,7 @@ static void stm32f2xx_timer_init(Object *obj)
 sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq);

 memory_region_init_io(&s->iomem, obj, &stm32f2xx_timer_ops, s,
-  "stm32f2xx_timer", 0x4000);
+  "stm32f2xx_timer", 0x400);
 sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->iomem);

 s->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, stm32f2xx_timer_interrupt,
s);
-- 
2.11.0

[Qemu-devel] [PATCH] hw/arm/stm32f205: Fix the UART and Timer region size

[Seth K]

From: Seth Kintigh 

I corrected these 2 memory regions based on specifications from the chip
manufacturer. The existing ranges seem to overlap and and cause odd
behavior and/or crashes when trying to set up multiple UARTs,

Signed-off-by: Seth Kintigh 
---
Phil, I hope this is the right format.

PMM, my original changes were made on an old version, but I made the patch
from the latest version per the instructions. I'm glad to hear that serial
port limit is gone!

 hw/char/stm32f2xx_usart.c  | 2 +-
 hw/timer/stm32f2xx_timer.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c
index 032b5fda13..f3363a2952 100644
--- a/hw/char/stm32f2xx_usart.c
+++ b/hw/char/stm32f2xx_usart.c
@@ -202,7 +202,7 @@ static void stm32f2xx_usart_init(Object *obj)
 sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq);

 memory_region_init_io(&s->mmio, obj, &stm32f2xx_usart_ops, s,
-  TYPE_STM32F2XX_USART, 0x2000);
+  TYPE_STM32F2XX_USART, 0x400);
 sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
 }

diff --git a/hw/timer/stm32f2xx_timer.c b/hw/timer/stm32f2xx_timer.c
index 58fc7b1188..ae744d1642 100644
--- a/hw/timer/stm32f2xx_timer.c
+++ b/hw/timer/stm32f2xx_timer.c
@@ -308,7 +308,7 @@ static void stm32f2xx_timer_init(Object *obj)
 sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq);

 memory_region_init_io(&s->iomem, obj, &stm32f2xx_timer_ops, s,
-  "stm32f2xx_timer", 0x4000);
+  "stm32f2xx_timer", 0x400);
 sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->iomem);

 s->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, stm32f2xx_timer_interrupt,
s);


On Thu, Nov 15, 2018 at 7:05 AM Peter Maydell 
wrote:

> On 4 November 2018 at 07:42, Seth K  wrote:
> > I corrected these 2 memory regions based on specifications from the chip
> > manufacturer. The existing ranges seem to overlap and and cause odd
> > behavior and/or crashes when trying to set up multiple UARTs,
> > I also played with changing MAX_SERIAL_PORTS to 8 to match the hardware,
> > but I did not include that in this patch as I never fully tested its
> > effects.
>
> Hi; thanks for the patch. As Philippe says, it looks good,
> but the one thing we definitely need is a Signed-off-by:
> line from you.
>
> A minor note -- there is no "MAX_SERIAL_PORTS" definition
> in QEMU any more: we removed that artificial limitation
> earlier this year. Maybe you're basing your patch on an
> older version of QEMU? It's best to use git master for
> development. Our SoC model defines 6 uarts (STM_NUM_USARTS)
> in hw/arm/stm32f205_soc.c, which should all now be connectable
> on the command line, though I haven't tested that or checked
> whether the hardware has 6 or some other number...
>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PATCH] hw/arm/stm32f205: Fix the UART and Timer region size

[Seth K]

Thanks for all your help and I'm glad to contribute.
Seth

On Tue, Nov 20, 2018 at 12:15 PM Alistair Francis 
wrote:

> On Mon, Nov 19, 2018 at 3:35 AM Philippe Mathieu-Daudé 
> wrote:
> >
> > On Mon, Nov 19, 2018 at 12:08 PM Peter Maydell 
> wrote:
> > > On 19 November 2018 at 10:43, Philippe Mathieu-Daudé 
> wrote:
> > > > Hi Seth,
> > > >
> > > > On Mon, Nov 19, 2018 at 4:17 AM Seth K  wrote:
> > > >>
> > > >> From: Seth Kintigh 
> > > >>
> > > >> I corrected these 2 memory regions based on specifications from the
> chip
> > > >> manufacturer. The existing ranges seem to overlap and and cause odd
> > > >> behavior and/or crashes when trying to set up multiple UARTs,
> > > >>
> > > >> Signed-off-by: Seth Kintigh 
> > > >> ---
> > > >> Phil, I hope this is the right format.
> > > >
> > > > Better but still incorrect.
> > >
> > > What Phil says below is true, but since this is a simple
> > > patch I have applied it by hand to my target-arm.next branch,
> > > so it will go into the next release of QEMU. Thanks for your
> > > contribution! (I rewrote the commit message a bit to make
> > > it fit in with the usual style we use for our commit messages;
> > > I hope that's OK.)
> >
> > Thanks Peter!
> >
> > You can also add:
> > Reviewed-by: Philippe Mathieu-Daudé 
> > Tested-by: Philippe Mathieu-Daudé 
> >
> > Regards,
>
> Thanks for applying this Peter and thanks for the patch Seth.
>
> Alistair
>
> >
> > Phil.
> >
> > >
> > > > I tried to apply your patch but get an error:
> > > >
> > > > $ git am seth_stm32f2xx_regsize.mbox
> > >
> > > I suspect this is because the email is in dual text/HTML format.
> > >
> > > thanks
> > > -- PMM
> >
>

[Qemu-devel] Simulating 3 chips on one board

[Seth K]

I need to simulate 3 chips that are on one board and that talk to each
other through UART, SPI and GPIO. The chips verify each other's work, and I
need to be able to observe this communication for debugging. Can something
like this be done in QEMU?

My first thought was to create the chip then create a board/machine with 1
chip, and run 3 instances of QEMU on the host and have them talk to each
other via the host (/dev/uart7 for example) but that doesn't seem to be
possible. It seems QEMU cannot output 8 UARTS (I can't get more than 1) or
any GPIOs. Is that correct? Not sure about SPIs either.

My next thought was to make 1 board with all three chips, but have some way
to sniff the UARTs/SPIs/GPIOs between chips. Is that possible in QEMU?

Thank you!
Seth

[Qemu-devel] [PATCH] Video and sound capture to a videofile through ffmpeg

[Alex K]

Hello everyone,

I've made a patch that adds ability to record video of what's going on
inside qemu. It uses ffmpeg libraries. Basically, the patch adds
2 new commands to the console:
capture_start path framerate
capture_stop

path is required
framerate could be 24, 25, 30 or 60. Default is 60
video codec is always h264

The patch uses ffmpeg so you will need to install these packages:
ffmpeg libavformat-dev libavcodec-dev libavutil-dev libswscale-dev

This is my first time posting here, so please correct me if I'm doing
something wrong

Signed-off-by: Alex K 
---
 configure  |  20 +
 default-configs/i386-softmmu.mak   |   1 +
 default-configs/x86_64-softmmu.mak |   1 +
 hmp-commands.hx|  34 ++
 hmp.h  |   2 +
 hw/display/Makefile.objs   |   2 +
 hw/display/capture.c   | 761 +
 hw/display/capture.h   |  78 
 8 files changed, 899 insertions(+)
 create mode 100644 hw/display/capture.c
 create mode 100644 hw/display/capture.h

diff --git a/configure b/configure
index 48a9370..a6ddbf0 100755
--- a/configure
+++ b/configure
@@ -281,6 +281,7 @@ opengl=""
 opengl_dmabuf="no"
 avx2_opt="no"
 zlib="yes"
+libav="yes"
 lzo=""
 snappy=""
 bzip2=""
@@ -1993,6 +1994,25 @@ if test "$seccomp" != "no" ; then
 seccomp="no"
 fi
 fi
+#
+# libav check
+
+if test "$libav" != "no" ; then
+cat > $TMPC << EOF
+#include 
+#include 
+
+int main(void){ av_register_all(); avcodec_register_all(); return 0; }
+EOF
+if compile_prog "" "-lm -lpthread -lavformat -lavcodec -lavutil -lswscale 
-lswresample" ; then
+:
+else
+error_exit "libav check failed" \
+"Make sure to have the libav libs and headers installed."
+fi
+fi
+LIBS="$LIBS -lm -lpthread -lavformat -lavcodec -lavutil -lswscale -lswresample"
+
 ##
 # xen probe
 
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index d2ab2f6..35ce513 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -59,3 +59,4 @@ CONFIG_SMBIOS=y
 CONFIG_HYPERV_TESTDEV=$(CONFIG_KVM)
 CONFIG_PXB=y
 CONFIG_ACPI_VMGENID=y
+CONFIG_CAPTURE=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index 9bde2f1..b9a7175 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -59,3 +59,4 @@ CONFIG_SMBIOS=y
 CONFIG_HYPERV_TESTDEV=$(CONFIG_KVM)
 CONFIG_PXB=y
 CONFIG_ACPI_VMGENID=y
+CONFIG_CAPTURE=y
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 0aca984..9066aac 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1809,3 +1809,37 @@ ETEXI
 STEXI
 @end table
 ETEXI
+
+{
+.name   = "capture_start",
+.args_type  = "filename:F,fps:i?",
+.params = "filename [framerate]",
+.help   = "Start video capture",
+.cmd= hmp_capture_start,
+},
+
+STEXI
+@item capture_start @var{filename} [@var{framerate}]
+@findex capture_start
+Start video capture.
+Capture video into @var{filename} with framerate @var{framerate}.
+
+Defaults:
+@itemize @minus
+@item framerate = 60
+@end itemize
+ETEXI
+
+{
+.name   = "capture_stop",
+.args_type  = "",
+.params = "",
+.help   = "Stop video capture",
+.cmd= hmp_capture_stop,
+},
+
+STEXI
+@item capture_stop
+@findex capture_stop
+Stop video capture.
+ETEXI
diff --git a/hmp.h b/hmp.h
index 799fd37..36c7a4d 100644
--- a/hmp.h
+++ b/hmp.h
@@ -138,5 +138,7 @@ void hmp_rocker_of_dpa_groups(Monitor *mon, const QDict 
*qdict);
 void hmp_info_dump(Monitor *mon, const QDict *qdict);
 void hmp_hotpluggable_cpus(Monitor *mon, const QDict *qdict);
 void hmp_info_vm_generation_id(Monitor *mon, const QDict *qdict);
+void hmp_capture_start(Monitor *mon, const QDict *qdict);
+void hmp_capture_stop(Monitor *mon, const QDict *qdict);
 
 #endif
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 551c050..a918896 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -20,6 +20,8 @@ common-obj-$(CONFIG_ZAURUS) += tc6393xb.o
 
 common-obj-$(CONFIG_MILKYMIST_TMU2) += milkymist-tmu2.o
 
+obj-$(CONFIG_CAPTURE) += capture.o
+
 obj-$(CONFIG_OMAP) += omap_dss.o
 obj-$(CONFIG_OMAP) += omap_lcdc.o
 obj-$(CONFIG_PXA2XX) += pxa2xx_lcd.o
diff --git a/hw/display/capture.c b/hw/display/capture.c
new file mode 100644
index 000..c89aaa0
--- /dev/null
+++ b/hw/display/capture.c
@@ -0,0 +1,761 @@
+#include "capture.h"
+
+static void sound_capture_notify(void *opaque

[Bug 1893040] Re: External modules retreval using Go1.15 on s390x appears to have checksum and ECDSA verification issues

[Matt K]

It's still an issue using qemu-6.0.0-rc4. If you remove the environment
variable ENV GOPROXY="https://proxy.golang.org|direct" you get a
different error:

 => ERROR [6/6] RUN go build .  

   5.8s
--
 > [6/6] RUN go build .:
#10 0.854 go: finding module for package rsc.io/quote
#10 4.138 fatal error: grew heap, but no adequate free space found
#10 4.159
#10 4.159 runtime stack:
#10 4.163 runtime.throw(0x62abce, 0x2b)
#10 4.172   /usr/local/go/src/runtime/panic.go:1116 +0x70
#10 4.183 runtime.(*mheap).allocSpan(0x9d5c60, 0x1, 0x100, 
0x9f1920, 0x96c720)
#10 4.199   /usr/local/go/src/runtime/mheap.go:1166 +0x896

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

Title:
   External modules retreval using Go1.15 on s390x appears to have
  checksum and ECDSA verification issues

Status in QEMU:
  New

Bug description:
  We are observing issue while building go-runner image and we suspect it is 
due to QEMU version being used. As referred in below issue:
  https://github.com/golang/go/issues/40949

  We tried to build go-runner image using go1.15 and register QEMU
  (docker run --rm --privileged multiarch/qemu-user-
  static@sha256:c772ee1965aa0be9915ee1b018a0dd92ea361b4fa1bcab5bbc033517749b2af4
  --reset -p yes) as mentioned in PR
  https://github.com/kubernetes/release/pull/1499. We observed below
  failure during build:

  
-
  ERROR: executor failed running [/bin/sh -c CGO_ENABLED=0 GOOS=linux 
GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"'
 -o go-runner ${package}]: buildkit-runc did not terminate successfully
  --
   > [builder 7/7] RUN CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build 
-ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner .:
  --
  failed to solve: rpc error: code = Unknown desc = executor failed running 
[/bin/sh -c CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s 
-w -buildid= -extldflags "-static"' -o go-runner ${package}]: buildkit-runc 
did not terminate successfully
  Makefile:52: recipe for target 'container' failed
  make: *** [container] Error 1
  
-

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

[Bug 1907817] [NEW] qemu-aarch64 tcg assertion v5.2.0

[Matus K]

Public bug reported:

After updating to 5.2 I am getting following assertion error:
qemu-aarch64: ../tcg/tcg-op-gvec.c:54: check_size_align: Assertion `(maxsz & 
max_align) == 0' failed.

I think it was introduced by commit:
e2e7168a214b0ed98dc357bba96816486a289762

Becasue before this change, in function simd_desc only maxsz % 8 == 0 was 
checked, but after this change qemu check for following:
 
max_align = maxsz >= 16 ? 15 : 7;
tcg_debug_assert((maxsz & max_align) == 0);  <--- here assertion happens

in my case maxsz=56.


Whole backtrace:
#4  0x004000314770 in check_size_align (oprsz=56, maxsz=56, ofs=0) at 
../tcg/tcg-op-gvec.c:54
#5  0x004000314950 in simd_desc (oprsz=56, maxsz=56, data=0) at 
../tcg/tcg-op-gvec.c:89
#6  0x004000316270 in do_dup (vece=0, dofs=3144, oprsz=56, maxsz=56, 
in_32=0x0, in_64=0x0, in_c=0) at ../tcg/tcg-op-gvec.c:630
#7  0x0040003164d0 in expand_clr (dofs=3144, maxsz=56) at 
../tcg/tcg-op-gvec.c:679
#8  0x004000319bb0 in tcg_gen_gvec_mov (vece=3, dofs=3136, aofs=3136, 
oprsz=8, maxsz=64) at ../tcg/tcg-op-gvec.c:1538
#9  0x004000200dc0 in clear_vec_high (s=0x40021a8180, is_q=false, rd=0) at 
../target/arm/translate-a64.c:592
#10 0x004000200e40 in write_fp_dreg (s=0x40021a8180, reg=0, v=0x1108) at 
../target/arm/translate-a64.c:600
--Type  for more, q to quit, c to continue without paging--
#11 0x004000200e90 in write_fp_sreg (s=0x40021a8180, reg=0, v=0x1060) at 
../target/arm/translate-a64.c:608
#12 0x004000214210 in handle_fpfpcvt (s=0x40021a8180, rd=0, rn=0, opcode=2, 
itof=true, rmode=0, scale=64, sf=0, type=0)
at ../target/arm/translate-a64.c:6988
#13 0x004000214f90 in disas_fp_int_conv (s=0x40021a8180, insn=505544704) at 
../target/arm/translate-a64.c:7299
#14 0x004000215350 in disas_data_proc_fp (s=0x40021a8180, insn=505544704) 
at ../target/arm/translate-a64.c:7389
#15 0x00400022aa70 in disas_data_proc_simd_fp (s=0x40021a8180, 
insn=505544704) at ../target/arm/translate-a64.c:14494
#16 0x00400022af90 in disas_a64_insn (env=0x7fac59b6b490, s=0x40021a8180) 
at ../target/arm/translate-a64.c:14663
#17 0x00400022b750 in aarch64_tr_translate_insn (dcbase=0x40021a8180, 
cpu=0x7fac59b63150) at ../target/arm/translate-a64.c:14823
#18 0x0040002e8630 in translator_loop (ops=0x4000902e00 
, db=0x40021a8180, cpu=0x7fac59b63150, 
tb=0x7fac3419c5c0, max_insns=512) at ../accel/tcg/translator.c:103
#19 0x0040002e3a60 in gen_intermediate_code (cpu=0x7fac59b63150, 
tb=0x7fac3419c5c0, max_insns=512)
at ../target/arm/translate.c:9283
#20 0x0040002fed30 in tb_gen_code (cpu=0x7fac59b63150, pc=4458820, 
cs_base=0, flags=2148544819, cflags=-16777216)
at ../accel/tcg/translate-all.c:1744
#21 0x00400036a6e0 in tb_find (cpu=0x7fac59b63150, last_tb=0x7fac3419c400, 
tb_exit=0, cf_mask=0) at ../accel/tcg/cpu-exec.c:414
--Type  for more, q to quit, c to continue without paging--
#22 0x00400036b040 in cpu_exec (cpu=0x7fac59b63150) at 
../accel/tcg/cpu-exec.c:770
#23 0x004000113a90 in cpu_loop (env=0x7fac59b6b490) at 
../linux-user/aarch64/cpu_loop.c:84
#24 0x0040002fb8c0 in main (argc=2, argv=0x40021a8e68, envp=0x40021a8e80) 
at ../linux-user/main.c:864

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: assertion tcg v5.2.0

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

Title:
  qemu-aarch64 tcg assertion v5.2.0

Status in QEMU:
  New

Bug description:
  After updating to 5.2 I am getting following assertion error:
  qemu-aarch64: ../tcg/tcg-op-gvec.c:54: check_size_align: Assertion `(maxsz & 
max_align) == 0' failed.

  I think it was introduced by commit:
  e2e7168a214b0ed98dc357bba96816486a289762

  Becasue before this change, in function simd_desc only maxsz % 8 == 0 was 
checked, but after this change qemu check for following:
   
  max_align = maxsz >= 16 ? 15 : 7;
  tcg_debug_assert((maxsz & max_align) == 0);  <--- here assertion happens

  in my case maxsz=56.

  
  Whole backtrace:
  #4  0x004000314770 in check_size_align (oprsz=56, maxsz=56, ofs=0) at 
../tcg/tcg-op-gvec.c:54
  #5  0x004000314950 in simd_desc (oprsz=56, maxsz=56, data=0) at 
../tcg/tcg-op-gvec.c:89
  #6  0x004000316270 in do_dup (vece=0, dofs=3144, oprsz=56, maxsz=56, 
in_32=0x0, in_64=0x0, in_c=0) at ../tcg/tcg-op-gvec.c:630
  #7  0x0040003164d0 in expand_clr (dofs=3144, maxsz=56) at 
../tcg/tcg-op-gvec.c:679
  #8  0x004000319bb0 in tcg_gen_gvec_mov (vece=3, dofs=3136, aofs=3136, 
oprsz=8, maxsz=64) at ../tcg/tcg-op-gvec.c:1538
  #9  0x004000200dc0 in clear_vec_high (s=0x40021a8180, is_q=false, rd=0) 
at ../target/arm/translate-a64.c:592
  #10 0x004000200e40 in write_fp_dreg (s=0x40021a8180, reg=0, v=0x1108) at 
../target/arm/translate-a64.c:600
  --Type  for more, q to quit, c to continue without paging--
  #11 0x004000200e90 in write_fp_sreg (s=0x40021a8180, reg

[Bug 1897481] [NEW] qemu crashes with VGA pass-through, e-GPU, nvidia 1060

[Sergiy K]

Public bug reported:

I try to pass-through nvidia 1060 6gb card, which is connected via
ExpressCard (EXP-GDC converter).

I can successfully run my virtual machine without pass-through, but when
I try to add the devices, qemu crashes.

The coredump contains:

Stack trace of thread 3289311:
#0  0x00614c49 memory_region_update_container_subregions 
(qemu-system-x86_64 + 0x214c49)
#1  0x005c0e8c vfio_probe_nvidia_bar0_quirk (qemu-system-x86_64 + 
0x1c0e8c)
#2  0x005bcec0 vfio_realize (qemu-system-x86_64 + 0x1bcec0)
#3  0x0079b423 pci_qdev_realize (qemu-system-x86_64 + 0x39b423)
#4  0x006facda device_set_realized (qemu-system-x86_64 + 0x2facda)
#5  0x00887e57 property_set_bool (qemu-system-x86_64 + 0x487e57)
#6  0x0088ac48 object_property_set (qemu-system-x86_64 + 0x48ac48)
#7  0x0088d1d2 object_property_set_qobject (qemu-system-x86_64 + 
0x48d1d2)
#8  0x0088b1f7 object_property_set_bool (qemu-system-x86_64 + 0x48b1f7)
#9  0x00693785 qdev_device_add (qemu-system-x86_64 + 0x293785)
#10 0x0061aad0 device_init_func (qemu-system-x86_64 + 0x21aad0)
#11 0x0098c87b qemu_opts_foreach (qemu-system-x86_64 + 0x58c87b)
#12 0x006211cb qemu_init (qemu-system-x86_64 + 0x2211cb)
#13 0x005002aa main (qemu-system-x86_64 + 0x1002aa)
#14 0x7fce8af21152 __libc_start_main (libc.so.6 + 0x28152)
#15 0x0050087e _start (qemu-system-x86_64 + 0x10087e)

The whole running command is pretty long, since I use libvirt to manage
my machines:

LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \
HOME=/var/lib/libvirt/qemu/domain-2-Win10 \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.cache \
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.config \
QEMU_AUDIO_DRV=spice \
/usr/bin/qemu-system-x86_64 \
-name guest=Win10,debug-threads=on \
-S \
-blockdev 
'{"driver":"file","filename":"/usr/share/edk2-ovmf/x64/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 
'{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
 \
-blockdev 
'{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/Win10_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 
'{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}'
 \
-machine 
pc-q35-5.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format
 \
-cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff \
-m 8192 \
-overcommit mem-lock=off \
-smp 2,sockets=2,cores=1,threads=1 \
-uuid 7043c77b-4903-4527-8089-9679d9a17fee \
-no-user-config \
-nodefaults \
-chardev stdio,mux=on,id=charmonitor \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=localtime,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot strict=on \
-device 
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
 \
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
-blockdev '{"driver":"file","filename":"/home/sergiy/VirtualBox 
VMs/win4games.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 
'{"node-name":"libvirt-2-format","read-only":false,"driver":"raw","file":"libvirt-2-storage"}'
 \
-device ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1 \
-blockdev 
'{"driver":"file","filename":"/home/sergiy/Downloads/Win10_2004_Ukrainian_x64.iso","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 
'{"node-name":"libvirt-1-format","read-only":true,"driver":"raw","file":"libvirt-1-storage"}'
 \
-device ide-cd,bus=ide.1,drive=libvirt-1-format,id=sata0-0-1 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev spicevmc,id=charchannel0,name=vdagent \
-device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 \
-spice 
port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on
 \
-device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1
 \
-chardev spicevmc,id=charredir0,name=usbredir \
-device usb-redir,chardev=charredir0,id=

[Bug 1897481] Re: qemu crashes with VGA pass-through, e-GPU, nvidia 1060

[Sergiy K]

dmesg:

[0.00] microcode: microcode updated early to revision 0x21, date = 
2019-02-13
[0.00] Linux version 5.8.6-1-MANJARO (builder@db927223e331) (gcc (GCC) 
10.2.0, GNU ld (GNU Binutils) 2.35) #1 SMP PREEMPT Thu Sep 3 14:19:36 UTC 2020
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.8-x86_64 
root=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 rw 
resume=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 resume_offset=7829504 
intel_iommu=on quiet resume=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 
resume_offset=7829504 intel_iommu=on
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Hygon HygonGenuine
[0.00]   Centaur CentaurHauls
[0.00]   zhaoxin   Shanghai  
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008] usable
[0.00] BIOS-e820: [mem 0x0009-0x000b] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable
[0.00] BIOS-e820: [mem 0x40004000-0x40004fff] reserved
[0.00] BIOS-e820: [mem 0x40005000-0xcfef6fff] usable
[0.00] BIOS-e820: [mem 0xcfef7000-0xd00f8fff] reserved
[0.00] BIOS-e820: [mem 0xd00f9000-0xd684efff] usable
[0.00] BIOS-e820: [mem 0xd684f000-0xd6a4efff] type 20
[0.00] BIOS-e820: [mem 0xd6a4f000-0xdae9efff] reserved
[0.00] BIOS-e820: [mem 0xdae9f000-0xdaf9efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data
[0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable
[0.00] BIOS-e820: [mem 0xdb00-0xdf9f] reserved
[0.00] BIOS-e820: [mem 0xf80f8000-0xf80f8fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00041e5f] usable
[0.00] BIOS-e820: [mem 0x00041e60-0x00041eff] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by Lenovo
[0.00] efi: ACPI 2.0=0xdaffe014 ACPI=0xdaffe000 SMBIOS=0xdae9e000 
[0.00] SMBIOS 2.7 present.
[0.00] DMI: LENOVO 2325KZ5/2325KZ5, BIOS G2ETB5WW (2.75 ) 04/09/2019
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 2594.172 MHz processor
[0.000921] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.000923] e820: remove [mem 0x000a-0x000f] usable
[0.000929] last_pfn = 0x41e600 max_arch_pfn = 0x4
[0.000933] MTRR default type: uncachable
[0.000934] MTRR fixed ranges enabled:
[0.000935]   0-9 write-back
[0.000936]   A-B uncachable
[0.000937]   C-F write-protect
[0.000938] MTRR variable ranges enabled:
[0.000939]   0 base 0FFC0 mask FFFC0 write-protect
[0.000940]   1 base 0 mask F8000 write-back
[0.000941]   2 base 08000 mask FC000 write-back
[0.000942]   3 base 0C000 mask FE000 write-back
[0.000943]   4 base 0DC00 mask FFC00 uncachable
[0.000944]   5 base 0DB00 mask FFF00 uncachable
[0.000944]   6 base 1 mask F write-back
[0.000945]   7 base 2 mask E write-back
[0.000946]   8 base 4 mask FE000 write-back
[0.000947]   9 base 41F00 mask FFF00 uncachable
[0.001364] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.001580] last_pfn = 0xdb000 max_arch_pfn = 0x4
[0.011180] check: Scanning 1 areas for low memory corruption
[0.011968] Secure boot could not be determined
[0.011969] RAMDISK: [mem 0x3676b000-0x373acfff]
[0.011975] ACPI: Early table checksum verification disabled
[0.011979] ACPI: RSDP 0xDAFFE014 24 (v02 LENOVO)
[0.011982] ACPI: XSDT 0xDAFFE170 C4 (v01 LENOVO TP-G2
2750 PTL  0002)
[0.011988] ACPI: FACP 0xDAFE5000 00010C (v05 LENOVO TP-G2
2750 PTL  0002)
[0.011994] ACPI: DSDT 0xDAFE7000 011383 (v01 LENOVO TP-G2
2750 INTL 20061109)
[0.011997] ACPI: FACS 0xDAF5A000 40
[0.012000] ACPI: SLIC 0xDAFFD000 000176 (v01 LEN

[Bug 1897481] Re: qemu crashes with VGA pass-through, e-GPU, nvidia 1060

[Sergiy K]

Thank you Alex for answering me.

It seems, I've got it working, if I boot the host with the connected GPU from 
the very beginning. 
Previously, I tried hotplug and it crashes. 

So previously I had:
  1. enable the host
  2. enable GPU
  3. connect the cable

And this time I tried:
  1. enable GPU
  2. connect the cable
  3. enable the host

And this works great. Actually, I was able to install nvidia drivers to
the Win10 guest and it runs well.

Now, I'm not sure if there is a bug. From one side, it might be an
expected requirement to exclude hotplug. From the other side, every
crash is a bug, so there can be an extra check for that. It's up to you
guys.

I'm thankful for your hard work and for the rocket science technologies
I can use with my laptop.

I'm attaching dmesg for the fresh boot host with the GPU connected from
the very beginning.

P.S. I'm sorry for the big files. I've just noticed the ability to
upload attachments.


** Attachment added: "dmesg for the working case"
   https://bugs.launchpad.net/qemu/+bug/1897481/+attachment/5415643/+files/dmesg

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

Title:
  qemu crashes with VGA pass-through, e-GPU, nvidia 1060

Status in QEMU:
  New

Bug description:
  I try to pass-through nvidia 1060 6gb card, which is connected via
  ExpressCard (EXP-GDC converter).

  I can successfully run my virtual machine without pass-through, but
  when I try to add the devices, qemu crashes.

  The coredump contains:

  Stack trace of thread 3289311:
  #0  0x00614c49 memory_region_update_container_subregions 
(qemu-system-x86_64 + 0x214c49)
  #1  0x005c0e8c vfio_probe_nvidia_bar0_quirk (qemu-system-x86_64 + 
0x1c0e8c)
  #2  0x005bcec0 vfio_realize (qemu-system-x86_64 + 0x1bcec0)
  #3  0x0079b423 pci_qdev_realize (qemu-system-x86_64 + 0x39b423)
  #4  0x006facda device_set_realized (qemu-system-x86_64 + 0x2facda)
  #5  0x00887e57 property_set_bool (qemu-system-x86_64 + 0x487e57)
  #6  0x0088ac48 object_property_set (qemu-system-x86_64 + 0x48ac48)
  #7  0x0088d1d2 object_property_set_qobject (qemu-system-x86_64 + 
0x48d1d2)
  #8  0x0088b1f7 object_property_set_bool (qemu-system-x86_64 + 
0x48b1f7)
  #9  0x00693785 qdev_device_add (qemu-system-x86_64 + 0x293785)
  #10 0x0061aad0 device_init_func (qemu-system-x86_64 + 0x21aad0)
  #11 0x0098c87b qemu_opts_foreach (qemu-system-x86_64 + 0x58c87b)
  #12 0x006211cb qemu_init (qemu-system-x86_64 + 0x2211cb)
  #13 0x005002aa main (qemu-system-x86_64 + 0x1002aa)
  #14 0x7fce8af21152 __libc_start_main (libc.so.6 + 0x28152)
  #15 0x0050087e _start (qemu-system-x86_64 + 0x10087e)

  The whole running command is pretty long, since I use libvirt to
  manage my machines:

  LC_ALL=C \
  PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \
  HOME=/var/lib/libvirt/qemu/domain-2-Win10 \
  XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.local/share \
  XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.cache \
  XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.config \
  QEMU_AUDIO_DRV=spice \
  /usr/bin/qemu-system-x86_64 \
  -name guest=Win10,debug-threads=on \
  -S \
  -blockdev 
'{"driver":"file","filename":"/usr/share/edk2-ovmf/x64/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}'
 \
  -blockdev 
'{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
 \
  -blockdev 
'{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/Win10_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}'
 \
  -blockdev 
'{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}'
 \
  -machine 
pc-q35-5.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format
 \
  -cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff \
  -m 8192 \
  -overcommit mem-lock=off \
  -smp 2,sockets=2,cores=1,threads=1 \
  -uuid 7043c77b-4903-4527-8089-9679d9a17fee \
  -no-user-config \
  -nodefaults \
  -chardev stdio,mux=on,id=charmonitor \
  -mon chardev=charmonitor,id=monitor,mode=control \
  -rtc base=localtime,driftfix=slew \
  -global kvm-pit.lost_tick_policy=delay \
  -no-hpet \
  -no-shutdown \
  -global ICH9-LPC.disable_s3=1 \
  -global ICH9-LPC.disable_s4=1 \
  -boot strict=on \
  -device 
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
 \
  -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
  -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
  -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
  -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
  -device

[Bug 1897481] Re: qemu crashes with VGA pass-through, e-GPU, nvidia 1060

[Sergiy K]

What's more interesting, it doesn't crash if I hotplug GPU after it was boot 
with it. So if I do
  
  1. enable GPU
  2. connect the cord
  3. enable the host
  4. run qemu (I'm not sure, if it's mandatory)
  5. disable cord
  6. disable GPU
  7. enable GPU
  8. enable cord
  9. run qemu again

qemu doesn't crash. but the windows guest doesn't load too - it just
hangs with a single core 100% load.

Not sure, if it's related, but trying to provide as much info as
possible

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

Title:
  qemu crashes with VGA pass-through, e-GPU, nvidia 1060

Status in QEMU:
  New

Bug description:
  I try to pass-through nvidia 1060 6gb card, which is connected via
  ExpressCard (EXP-GDC converter).

  I can successfully run my virtual machine without pass-through, but
  when I try to add the devices, qemu crashes.

  The coredump contains:

  Stack trace of thread 3289311:
  #0  0x00614c49 memory_region_update_container_subregions 
(qemu-system-x86_64 + 0x214c49)
  #1  0x005c0e8c vfio_probe_nvidia_bar0_quirk (qemu-system-x86_64 + 
0x1c0e8c)
  #2  0x005bcec0 vfio_realize (qemu-system-x86_64 + 0x1bcec0)
  #3  0x0079b423 pci_qdev_realize (qemu-system-x86_64 + 0x39b423)
  #4  0x006facda device_set_realized (qemu-system-x86_64 + 0x2facda)
  #5  0x00887e57 property_set_bool (qemu-system-x86_64 + 0x487e57)
  #6  0x0088ac48 object_property_set (qemu-system-x86_64 + 0x48ac48)
  #7  0x0088d1d2 object_property_set_qobject (qemu-system-x86_64 + 
0x48d1d2)
  #8  0x0088b1f7 object_property_set_bool (qemu-system-x86_64 + 
0x48b1f7)
  #9  0x00693785 qdev_device_add (qemu-system-x86_64 + 0x293785)
  #10 0x0061aad0 device_init_func (qemu-system-x86_64 + 0x21aad0)
  #11 0x0098c87b qemu_opts_foreach (qemu-system-x86_64 + 0x58c87b)
  #12 0x006211cb qemu_init (qemu-system-x86_64 + 0x2211cb)
  #13 0x005002aa main (qemu-system-x86_64 + 0x1002aa)
  #14 0x7fce8af21152 __libc_start_main (libc.so.6 + 0x28152)
  #15 0x0050087e _start (qemu-system-x86_64 + 0x10087e)

  The whole running command is pretty long, since I use libvirt to
  manage my machines:

  LC_ALL=C \
  PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \
  HOME=/var/lib/libvirt/qemu/domain-2-Win10 \
  XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.local/share \
  XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.cache \
  XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.config \
  QEMU_AUDIO_DRV=spice \
  /usr/bin/qemu-system-x86_64 \
  -name guest=Win10,debug-threads=on \
  -S \
  -blockdev 
'{"driver":"file","filename":"/usr/share/edk2-ovmf/x64/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}'
 \
  -blockdev 
'{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
 \
  -blockdev 
'{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/Win10_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}'
 \
  -blockdev 
'{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}'
 \
  -machine 
pc-q35-5.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format
 \
  -cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff \
  -m 8192 \
  -overcommit mem-lock=off \
  -smp 2,sockets=2,cores=1,threads=1 \
  -uuid 7043c77b-4903-4527-8089-9679d9a17fee \
  -no-user-config \
  -nodefaults \
  -chardev stdio,mux=on,id=charmonitor \
  -mon chardev=charmonitor,id=monitor,mode=control \
  -rtc base=localtime,driftfix=slew \
  -global kvm-pit.lost_tick_policy=delay \
  -no-hpet \
  -no-shutdown \
  -global ICH9-LPC.disable_s3=1 \
  -global ICH9-LPC.disable_s4=1 \
  -boot strict=on \
  -device 
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
 \
  -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
  -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
  -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
  -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
  -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
  -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \
  -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
  -blockdev '{"driver":"file","filename":"/home/sergiy/VirtualBox 
VMs/win4games.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}'
 \
  -blockdev 
'{"node-name":"libvirt-2-format","read-only":false,"driver":"raw","file":"libvirt-2-storage"}'
 \
  -device ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1 \
  -blockdev 
'{"driver":"file","filename":"/home/serg

[Bug 1897481] Re: qemu crashes with VGA pass-through, e-GPU, nvidia 1060

[Sergiy K]

Can confirm that it does not crash after applying that patch. I've added
the `fprintf` statement there:

if (vdev->bars[i].size) {
  vfio_bar_quirk_setup(vdev, i);
} else {
fprintf(stderr, "%04x:%04x bars for %d are empty\n", 
vdev->vendor_id, vdev->device_id, i);
}

and the output is:

10de:1c03 bars for 0 are empty
10de:1c03 bars for 1 are empty
10de:1c03 bars for 2 are empty
10de:1c03 bars for 3 are empty
10de:1c03 bars for 4 are empty
10de:10f1 bars for 1 are empty
10de:10f1 bars for 2 are empty
10de:10f1 bars for 3 are empty
10de:10f1 bars for 4 are empty
10de:10f1 bars for 5 are empty

What's interesting that 5 bar is available for VGA and 0 bar is
available for the sound. Don't know if it gives some valuable
information.

I understand that it's completely not a fault of QEMU, since the
underlying layer gives wrong information. Any insight about potential
problematic places? Is it completely a hardware issue (laptop's BIOS,
nvidia) or something can be done in software? What's the next place to
send a bugreport?

Thank you

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

Title:
  qemu crashes with VGA pass-through, e-GPU, nvidia 1060

Status in QEMU:
  New

Bug description:
  I try to pass-through nvidia 1060 6gb card, which is connected via
  ExpressCard (EXP-GDC converter).

  I can successfully run my virtual machine without pass-through, but
  when I try to add the devices, qemu crashes.

  The coredump contains:

  Stack trace of thread 3289311:
  #0  0x00614c49 memory_region_update_container_subregions 
(qemu-system-x86_64 + 0x214c49)
  #1  0x005c0e8c vfio_probe_nvidia_bar0_quirk (qemu-system-x86_64 + 
0x1c0e8c)
  #2  0x005bcec0 vfio_realize (qemu-system-x86_64 + 0x1bcec0)
  #3  0x0079b423 pci_qdev_realize (qemu-system-x86_64 + 0x39b423)
  #4  0x006facda device_set_realized (qemu-system-x86_64 + 0x2facda)
  #5  0x00887e57 property_set_bool (qemu-system-x86_64 + 0x487e57)
  #6  0x0088ac48 object_property_set (qemu-system-x86_64 + 0x48ac48)
  #7  0x0088d1d2 object_property_set_qobject (qemu-system-x86_64 + 
0x48d1d2)
  #8  0x0088b1f7 object_property_set_bool (qemu-system-x86_64 + 
0x48b1f7)
  #9  0x00693785 qdev_device_add (qemu-system-x86_64 + 0x293785)
  #10 0x0061aad0 device_init_func (qemu-system-x86_64 + 0x21aad0)
  #11 0x0098c87b qemu_opts_foreach (qemu-system-x86_64 + 0x58c87b)
  #12 0x006211cb qemu_init (qemu-system-x86_64 + 0x2211cb)
  #13 0x005002aa main (qemu-system-x86_64 + 0x1002aa)
  #14 0x7fce8af21152 __libc_start_main (libc.so.6 + 0x28152)
  #15 0x0050087e _start (qemu-system-x86_64 + 0x10087e)

  The whole running command is pretty long, since I use libvirt to
  manage my machines:

  LC_ALL=C \
  PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \
  HOME=/var/lib/libvirt/qemu/domain-2-Win10 \
  XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.local/share \
  XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.cache \
  XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.config \
  QEMU_AUDIO_DRV=spice \
  /usr/bin/qemu-system-x86_64 \
  -name guest=Win10,debug-threads=on \
  -S \
  -blockdev 
'{"driver":"file","filename":"/usr/share/edk2-ovmf/x64/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}'
 \
  -blockdev 
'{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
 \
  -blockdev 
'{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/Win10_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}'
 \
  -blockdev 
'{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}'
 \
  -machine 
pc-q35-5.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format
 \
  -cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff \
  -m 8192 \
  -overcommit mem-lock=off \
  -smp 2,sockets=2,cores=1,threads=1 \
  -uuid 7043c77b-4903-4527-8089-9679d9a17fee \
  -no-user-config \
  -nodefaults \
  -chardev stdio,mux=on,id=charmonitor \
  -mon chardev=charmonitor,id=monitor,mode=control \
  -rtc base=localtime,driftfix=slew \
  -global kvm-pit.lost_tick_policy=delay \
  -no-hpet \
  -no-shutdown \
  -global ICH9-LPC.disable_s3=1 \
  -global ICH9-LPC.disable_s4=1 \
  -boot strict=on \
  -device 
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
 \
  -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
  -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
  -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
  -device pcie-root-port,port=0x14,chass

[Bug 1897481] Re: qemu crashes with VGA pass-through, e-GPU, nvidia 1060

[Sergiy K]

I recorded both lspci - and lspci - for the following
connections:

  - hotplug: when GPU is connected after the host was loaded
  - fresh: when GPU is connected before the host was started

The main difference is the following:

1c1
< # hotplug
---
> # fresh
6c6
<   Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
---
>   Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
8c8
<   Interrupt: pin A routed to IRQ 18
---
>   Interrupt: pin A routed to IRQ 255
10,13c10,14
<   Region 1: Memory at  (64-bit, prefetchable) [disabled]
<   Region 3: Memory at  (64-bit, prefetchable) [disabled]
<   Region 5: I/O ports at 4000 [size=128]
<   Expansion ROM at f140 [virtual] [disabled] [size=512K]
---
>   Region 0: Memory at f000 (32-bit, non-prefetchable) [size=16M]
>   Region 1: Memory at c000 (64-bit, prefetchable) [size=256M]
>   Region 3: Memory at d000 (64-bit, prefetchable) [size=32M]
>   Region 5: I/O ports at 4000 [disabled] [size=128]
>   Expansion ROM at f108 [disabled] [size=512K]
30c31
<   LnkSta: Speed 5GT/s (downgraded), Width x1 (downgraded)
---
>   LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded)
35a37
>AtomicOpsCap: 32bit- 64bit- 128bitCAS-
79c81
<   Interrupt: pin B routed to IRQ 19
---
>   Interrupt: pin B routed to IRQ 255
81c83
<   Region 0: Memory at f148 (32-bit, non-prefetchable) [size=16K]
---
>   Region 0: Memory at f100 (32-bit, non-prefetchable) [size=16K]
98c100
<   LnkSta: Speed 5GT/s (downgraded), Width x1 (downgraded)
---
>   LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded)
124,125c126,127

I can tell, that hotplug connects as 5GT/s and fresh - 2.5GT/s. And
there is an obvious difference between Regions.

The difference between lspci - but I don't know how to interpret the
result:

124,125c126,127
< 00: de 10 03 1c 01 00 10 00 a1 00 00 03 00 00 80 00
< 10: 00 00 00 00 0c 00 00 00 00 00 00 00 0c 00 00 00
---
> 00: de 10 03 1c 02 00 10 00 a1 00 00 03 10 00 80 00
> 10: 00 00 00 f0 0c 00 00 c0 00 00 00 00 0c 00 00 d0
127c129
< 30: 00 00 00 00 60 00 00 00 00 00 00 00 00 01 00 00
---
> 30: 00 00 f8 ff 60 00 00 00 00 00 00 00 ff 01 00 00
132c134
< 80: 10 29 09 00 03 3d 45 00 43 01 12 10 00 00 00 00
---
> 80: 10 29 09 00 03 3d 45 00 43 01 11 10 00 00 00 00
198c200
< 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78
---
> 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff
221c223
< 610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
---
> 610: 01 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
257c259
< 850: 00 00 00 00 78 00 00 00 ff 3f 00 00 00 00 00 00
---
> 850: 00 00 00 00 af 04 00 00 ff 3f 00 00 00 00 00 00
382,383c384,385
< 00: de 10 f1 10 02 00 10 00 a1 00 03 04 00 00 80 00
< 10: 00 00 48 f1 00 00 00 00 00 00 00 00 00 00 00 00
---
> 00: de 10 f1 10 02 00 10 00 a1 00 03 04 10 00 80 00
> 10: 00 00 00 f1 00 00 00 00 00 00 00 00 00 00 00 00
385c387
< 30: 00 00 00 00 60 00 00 00 00 00 00 00 00 02 00 00
---
> 30: 00 00 00 00 60 00 00 00 00 00 00 00 ff 02 00 00
390c392
< 80: 10 29 09 00 03 3d 45 00 43 01 12 10 00 00 00 00
---
> 80: 10 29 09 00 03 3d 45 00 43 01 11 10 00 00 00 00
456,457c458,459
< 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78
< 4b0: 78 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
---
> 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff
> 4b0: af 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00


** Attachment added: "lspci-hotplug"
   
https://bugs.launchpad.net/qemu/+bug/1897481/+attachment/5417476/+files/lspci-hotplug

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

Title:
  qemu crashes with VGA pass-through, e-GPU, nvidia 1060

Status in QEMU:
  New

Bug description:
  I try to pass-through nvidia 1060 6gb card, which is connected via
  ExpressCard (EXP-GDC converter).

  I can successfully run my virtual machine without pass-through, but
  when I try to add the devices, qemu crashes.

  The coredump contains:

  Stack trace of thread 3289311:
  #0  0x00614c49 memory_region_update_container_subregions 
(qemu-system-x86_64 + 0x214c49)
  #1  0x005c0e8c vfio_probe_nvidia_bar0_quirk (qemu-system-x86_64 + 
0x1c0e8c)
  #2  0x005bcec0 vfio_realize (qemu-system-x86_64 + 0x1bcec0)
  #3  0x0079b423 pci_qdev_realize (qemu-system-x86_64 + 0x39b423)
  #4  0x006facda device_set_realized (qemu-system-x86_64 + 0x2facda)
  #5  0x00887e57 property_set_bool (qemu-system-x86_64 + 0x487e57)
  #6  0x0088ac48 object_property_set (qemu-system-x86_64 + 0x48ac48)
  #7  0x0088d1d2 object_property_set_qobject (qemu-system-x86_64 + 
0x48d1d2)
  #8  0x0088b1f7 object_property_set_bool (qemu-system-x86_64 + 
0x48b1f7)
  #9  

[Qemu-devel] QEMU for ARM920T

[Rashmi J K]

Hello

Can I run code compiled for ARM920T core in QEMU?

I am learning Embedded Linux for ARM processor. This is very crucial for my
studies. In future will have to work on AT91RM9200 atmel board with ARM920T
cpu.
Embedded Linux version that I am working on is 2.6.17.
I am struggling to set up an Emulator for this.
Could you please let me know if I can emulate ARM920T on QEMU?
If yes, could you please let me know some reference manuals, website link,
pdf's explaining the methods to set up QEMU for ARM920T.

Thanks
Rashmi

[Qemu-devel] qemu-i386 user mode on ARM

[Reuben K. Caron]

Qemu Dev's,

I have been reading through many mail archives about the issues with threading 
in qemu-i386 user mode.

I am writing now because here at One Laptop per Child we have a deployment 
looking to run simple Windows x86 executables using WINE on our new ARM 
platform. 

We are interested to know if there is an opportunity to fund a solution to this 
issue and if so, what kind of timeline could we expect for such a solution.

If you are interested in working on such a project please feel free to get in 
touch with me off-list.

I recently had an email exchange with Peter Maydell, where he kindly 
illustrated what he considered the major issues:

"You can probably divide the work into three parts:
(1) bringing target-i386 up to par with other targets for
multithreaded user programs (ie "works, but prone to random
crashes if using threads extensively"). This mostly amounts
to enabling the NPTL config setting, making sure we're handling
TLS correctly and fixing the issues with cross-thread exclusive
accesses (x86 LOCK prefix).
(2) fixing qemu user-mode's general multithreading crashiness
(ie finding and fixing race conditions in core code). I actually
have a patch lurking somewhere which deals with the worst one
of these.
(3) fixing any qemu user-mode emulation issues exposed by the
particular binaries you want to run. This is the "how long is
a piece of string" part, since you just have to keep fixing
bugs until the program runs. Simple programs don't generally
have issues here, but something complicated like Wine (I assume
you're going to be using Wine to run these Windows binaries)
probably does a few odd things that might give QEMU trouble.
Most of these fixes will be easy, but you might be unlucky.
(For instance there's a known issue trying to run programs
which use the Boehm garbage collector, whose fix is basically
"restructure the whole of linux-user mode so we can deal with
signals arriving in the middle of emulating system calls".)
(4) the nasty issue referred to above. This is specific to
running a strong-memory-model target like x86 on a weak
memory model host like ARM. QEMU just translates loads and
stores to loads and stores, so multithreaded programs that
rely on guarantees of the memory model about what order
other threads see memory accesses in might behave oddly,
because QEMU won't provide those guarantees. I have no
idea whether this would be an issue for real world code;
issues 1 to 3 are effectively hiding it. If it does turn
out to be a real problem, though, there's not much we can do
about it (short of emitting a memory barrier for every
load/store op, which would probably do bad things for
performance)."


Regards,

Reuben

Re: [Qemu-devel] [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Raghavendra K T]

On 12/26/2011 07:37 PM, Avi Kivity wrote:

On 12/19/2011 04:11 PM, Jan Kiszka wrote:


Backwards compatibility


If we want backwards compatibility, we need more than just a simple feature 
check, no? Oh, you feed that into CPUID? That's nifty. Ok, so you behave like 
VMX/SVM do on real hardware - you always expose the functionality but don't 
list it in CPUID for older user space.


Do we want this to be on when providing a compat machine type ("pc-0.12"
etc.) to the guest? Then it does need more work (see the dance around
kvmclock).


We do.  I have a feeling the whole cpuid stuff, paravirt and
non-paravirt, needs some fixing in this area.  It's different than the
normal compat code since not only qemu, but also kvm and the host cpu
have a say in what's supported and what's not.



Sorry, missed all threads except this due to some problem with mail
client config.  Yet to explore on what is to be done, But I  Agree for
the changes and work needed in this direction.

[Qemu-devel] [PATCH V2 1/1] QEMU kvm/i386 : Adding PVLOCK_KICK capability support in i386 target.

[Raghavendra K T]

From: Raghavendra K T 

The patch, extends KVM-hypervisor and Linux guest running on
KVM-hypervisor to support pv-ticket spinlocks.

PV ticket spinlock helps to solve Lock Holder Preemption problem discussed in
http://www.amd64.org/fileadmin/user_upload/pub/LHP-commented_slides.pdf.

When spinlock is contended,a guest vcpu relinqueshes cpu by halt().
Correspondingly, One hypercall is introduced in KVM hypervisor,that allows
a vcpu to kick the halted vcpu to continue with execution.

Note:
Below patch should be applied only after corresponding
linux-header changes taken into qemu via scripts/update-linux-headers.sh script.

TODO: There was a discussion on changing cpuid stuff, paravirt and non-paravirt
stuff to address backward compatibility/feature support with Avi and Jan.
But it is not addressed yet.

Changes in V2:
 Drop the syncing kernel header changes. (Alex) 
 rename KICK_VCPU --> PVLOCK_KICK.

Change log:
 Extend the KVM Hypervisor to enable PVLOCK_KICK feature that allows
a vcpu to kick the halted vcpu to continue with execution in PV ticket
spinlock.

Signed-off-by: Srivatsa Vaddagiri 
Signed-off-by: Raghavendra K T 
---
The corresponding kernel patch is available in the thread
 https://lkml.org/lkml/2012/1/14/66

older kernel patch:
 https://lkml.org/lkml/2011/11/30/62
older qemu-patch:
 http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00397.html

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 04e65c5..14de1c0 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -97,6 +97,7 @@ struct kvm_para_features {
 { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
 { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
 { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
+{ KVM_CAP_PVLOCK_KICK, KVM_FEATURE_PVLOCK_KICK },
 { -1, -1 }
 };
 

[Qemu-devel] [PATCH 0/2] QEMU kvm: Adding paravirtual spinlock support for x86.

[Raghavendra K T]

The patch, extends KVM-hypervisor and Linux guest running on
KVM-hypervisor to support pv-ticket spinlocks.

PV ticket spinlock helps to solve Lock Holder Preemption problem discussed in
http://www.amd64.org/fileadmin/user_upload/pub/LHP-commented_slides.pdf.

When spinlock is contended,a guest vcpu relinqueshes cpu by halt().
Correspondingly, One hypercall is introduced in KVM hypervisor,that allows
a vcpu to kick the halted vcpu to continue with execution.

Note:
Below patch should be applied only after corresponding
linux-header changes taken into qemu via scripts/update-linux-headers.sh script.
---
Changes in V3:
 rename PVLOCK_KICK --> PV_UNHALT
 add MSR related changes to aid migration

Changes in V2:
 Drop the syncing kernel header changes. (Alex) 
 rename KICK_VCPU --> PVLOCK_KICK.

Raghavendra K T(2):
 add PV_UNHALT feature support.
 add support to get/set vcpu unhalt msr to aid migration

 target-i386/cpu.h |1 +
 target-i386/kvm.c |   14 +-
 2 files changed, 14 insertions(+), 1 deletions(-)

V5 Kernel changes:
 https://lkml.org/lkml/2012/3/23/50

V4 kernel changes:
 https://lkml.org/lkml/2012/1/14/66
 Qemu changes for V4:
 http://www.mail-archive.com/kvm@vger.kernel.org/msg66450.html

 V3 kernel Changes:
 https://lkml.org/lkml/2011/11/30/62
 V2 kernel changes :
 https://lkml.org/lkml/2011/10/23/207

 Previous discussions : (posted by Srivatsa V).
 https://lkml.org/lkml/2010/7/26/24
 https://lkml.org/lkml/2011/1/19/212

 Qemu patch for V3:
 http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00397.html

[Qemu-devel] [PATCH 1/2] QEMU kvm: Add PV_UNHALT feature support

[Raghavendra K T]

From: Raghavendra K T 

Extend the KVM Hypervisor to enable PVLOCK_KICK feature that allows
a vcpu to kick the halted vcpu to continue with execution in PV ticket
spinlock.

Signed-off-by: Srivatsa Vaddagiri 
Signed-off-by: Raghavendra K T 
---
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index e74a9e4..dbebd3a 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -98,6 +98,7 @@ struct kvm_para_features {
 { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
 { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
 { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
+{ KVM_CAP_PV_UNHALT, KVM_FEATURE_PV_UNHALT },
 { -1, -1 }
 };
 

[Qemu-devel] [PATCH 2/2] QEMU kvm: Add support to get/set vcpu unhalt msr to aid migration

[Raghavendra K T]

From: Raghavendra K T 

MSR_KVM_PV_UNHALT tells whether vcpu is unhalted, which needs to be
used during migration.

Signed-off-by: Raghavendra K T 
---
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index a1ed3e7..10286a5 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -697,6 +697,7 @@ typedef struct CPUX86State {
 uint64_t system_time_msr;
 uint64_t wall_clock_msr;
 uint64_t async_pf_en_msr;
+uint64_t pv_unhalt_msr;
 
 uint64_t tsc;
 uint64_t tsc_deadline;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index dbebd3a..98b9088 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -62,6 +62,7 @@ static bool has_msr_star;
 static bool has_msr_hsave_pa;
 static bool has_msr_tsc_deadline;
 static bool has_msr_async_pf_en;
+static bool has_msr_pv_unhalt;
 static bool has_msr_misc_enable;
 static int lm_capable_kernel;
 
@@ -444,7 +445,7 @@ int kvm_arch_init_vcpu(CPUX86State *env)
 }
 
 has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
-
+has_msr_pv_unhalt = c->eax & (1 << KVM_FEATURE_PV_UNHALT);
 cpu_x86_cpuid(env, 0, 0, &limit, &unused, &unused, &unused);
 
 for (i = 0; i <= limit; i++) {
@@ -1012,6 +1013,10 @@ static int kvm_put_msrs(CPUX86State *env, int level)
 if (hyperv_vapic_recommended()) {
 kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
 }
+if (has_msr_pv_unhalt) {
+kvm_msr_entry_set(&msrs[n++], MSR_KVM_PV_UNHALT,
+  env->pv_unhalt_msr);
+}
 }
 if (env->mcg_cap) {
 int i;
@@ -1247,6 +1252,9 @@ static int kvm_get_msrs(CPUX86State *env)
 if (has_msr_async_pf_en) {
 msrs[n++].index = MSR_KVM_ASYNC_PF_EN;
 }
+if (has_msr_pv_unhalt) {
+msrs[n++].index = MSR_KVM_PV_UNHALT;
+}
 
 if (env->mcg_cap) {
 msrs[n++].index = MSR_MCG_STATUS;
@@ -1326,6 +1334,9 @@ static int kvm_get_msrs(CPUX86State *env)
 case MSR_KVM_ASYNC_PF_EN:
 env->async_pf_en_msr = msrs[i].data;
 break;
+case MSR_KVM_PV_UNHALT:
+env->pv_unhalt_msr = msrs[i].data;
+break;
 }
 }
 

Re: [Qemu-devel] [PATCH 2/2] QEMU kvm: Add support to get/set vcpu unhalt msr to aid migration

[Raghavendra K T]

On 03/23/2012 02:27 PM, Jan Kiszka wrote:

On 2012-03-23 09:23, Raghavendra K T wrote:

From: Raghavendra K T

MSR_KVM_PV_UNHALT tells whether vcpu is unhalted, which needs to be
used during migration.


Err, and where is it actually saved to/restored from the vmstate? You
are lacking an extension of the CPU vmstate, preferably via a substate.
See e.g. cpu/async_pf_msr.



Thanks Jan for review, I 'll check that.

Re: [Qemu-devel] [PATCH 2/2] QEMU kvm: Add support to get/set vcpu unhalt msr to aid migration

[Raghavendra K T]

On 03/23/2012 02:27 PM, Jan Kiszka wrote:

On 2012-03-23 09:23, Raghavendra K T wrote:

From: Raghavendra K T

MSR_KVM_PV_UNHALT tells whether vcpu is unhalted, which needs to be
used during migration.


Err, and where is it actually saved to/restored from the vmstate? You
are lacking an extension of the CPU vmstate, preferably via a substate.
See e.g. cpu/async_pf_msr.



Please let me know whether adding below patch make it complete. Or did
I miss something else ?

---
diff --git a/target-i386/machine.c b/target-i386/machine.c
index a8be058..c51d8d1 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -279,6 +279,13 @@ static bool async_pf_msr_needed(void *opaque)
 return cpu->async_pf_en_msr != 0;
 }

+static bool pv_unhalt_msr_needed(void *opaque)
+{
+CPUX86State *cpu = opaque;
+
+return cpu->pv_unhalt_msr != 0;
+}
+
 static const VMStateDescription vmstate_async_pf_msr = {
 .name = "cpu/async_pf_msr",
 .version_id = 1,
@@ -290,6 +297,17 @@ static const VMStateDescription 
vmstate_async_pf_msr = {

 }
 };

+static const VMStateDescription vmstate_pv_unhalt_msr = {
+.name = "cpu/pv_unhalt_msr",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields  = (VMStateField []) {
+VMSTATE_UINT64(pv_unhalt_msr, CPUX86State),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static bool fpop_ip_dp_needed(void *opaque)
 {
 CPUX86State *env = opaque;
@@ -462,6 +480,9 @@ static const VMStateDescription vmstate_cpu = {
 }, {
 .vmsd = &vmstate_msr_ia32_misc_enable,
 .needed = misc_enable_needed,
+}, {
+.vmsd = &vmstate_pv_unhalt_msr,
+.needed = pv_unhalt_msr_needed,
 } , {
 /* empty */
 }

[Qemu-devel] [PATCH] Added legacy 9P2000 support back into QEMU

[William K. Bittner]

It was tested with v9fs in the guest by using: sudo mount -t 9p -o 
trans=virtio,version=9p2000 v_boot /pmnt

Signed-off-by: William K. Bittner 

diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index b5fc52b..febfba2 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1186,6 +1186,8 @@ static void v9fs_version(V9fsState *s, V9fsPDU *pdu)
 s->proto_version = V9FS_PROTO_2000U;
 } else if (!strcmp(version.data, "9P2000.L")) {
 s->proto_version = V9FS_PROTO_2000L;
+} else if (!strcmp(version.data, "9P2000")) {
+s->proto_version = V9FS_PROTO_2000;
 } else {
 v9fs_string_sprintf(&version, "unknown");
 }
diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
index 622928f..c5b5229 100644
--- a/hw/9pfs/virtio-9p.h
+++ b/hw/9pfs/virtio-9p.h
@@ -94,6 +94,7 @@ enum {
 };
 
 enum p9_proto_version {
+V9FS_PROTO_2000  = 0x00,
 V9FS_PROTO_2000U = 0x01,
 V9FS_PROTO_2000L = 0x02,
 };
-- 
1.7.4.1

[Qemu-devel] [PATCH V8 1/1] Guest stop notification

[Raghavendra K T]

From: Eric B Munson 

Often when a guest is stopped from the qemu console, it will report spurious
soft lockup warnings on resume.  There are kernel patches being discussed that
will give the host the ability to tell the guest that it is being stopped and
should ignore the soft lockup warning that generates.  This patch uses the qemu
Notifier system to tell the guest it is about to be stopped.

Signed-off-by: Eric B Munson  
Signed-off-by: Raghavendra K T 

Cc: Eric B Munson 
Cc: Avi Kivity  
Cc: Marcelo Tosatti 
Cc: Anthony Liguori 
Cc: Jan Kiszka 
Cc: "Andreas Färber" 
---
Changes from V7:
 capabilty changed to KVM_CAP_KVMCLOCK_CTRL
 KVM_GUEST_PAUSED is pervcpu again
 CPUState renamed to CPUArchState
 KVMCLOCK_GUEST_PAUSED changed to  KVM_KVMCLOCK_CTRL

Changes from V6:
 Remove unnecessary include

Changes from V5:
 KVM_GUEST_PAUSED is now a per vm ioctl instead of per vcpu

Changes from V4:
 Test if the guest paused capability is available before use

Changes from V3:
 Collapse new state change notification function into existsing function.
 Correct whitespace issues
 Change ioctl name to KVMCLOCK_GUEST_PAUSED
 Use for loop to iterate vpcu's

Changes from V2:
 Move ioctl into hw/kvmclock.c so as other arches can use it as it is
implemented

Changes from V1:
 Remove unnecessary encapsulating function
---

diff --git a/hw/kvm/clock.c b/hw/kvm/clock.c
index 446bd62..c8a34a5 100644
--- a/hw/kvm/clock.c
+++ b/hw/kvm/clock.c
@@ -64,10 +64,28 @@ static int kvmclock_post_load(void *opaque, int version_id)
 static void kvmclock_vm_state_change(void *opaque, int running,
  RunState state)
 {
+int ret;
 KVMClockState *s = opaque;
+CPUArchState *penv = first_cpu;
+int cap_clock_ctrl = kvm_check_extension(kvm_state, KVM_CAP_KVMCLOCK_CTRL);
 
 if (running) {
 s->clock_valid = false;
+
+if (!cap_clock_ctrl) {
+return;
+}
+for (penv = first_cpu; penv != NULL; penv = penv->next_cpu) {
+ret = kvm_vcpu_ioctl(penv, KVM_KVMCLOCK_CTRL, 0);
+if (ret) {
+if (ret != -EINVAL) {
+fprintf(stderr,
+"kvmclock_vm_state_change: %s\n",
+strerror(-ret));
+}
+return;
+}
+}
 }
 }
 

Re: [Qemu-devel] [PATCH V8 1/1] Guest stop notification

[Raghavendra K T]

On 04/06/2012 02:29 PM, Andreas Färber wrote:

Am 06.04.2012 09:21, schrieb Raghavendra K T:

From: Eric B Munson

Often when a guest is stopped from the qemu console, it will report spurious
soft lockup warnings on resume.  There are kernel patches being discussed that
will give the host the ability to tell the guest that it is being stopped and
should ignore the soft lockup warning that generates.  This patch uses the qemu
Notifier system to tell the guest it is about to be stopped.

Signed-off-by: Eric B Munson
Signed-off-by: Raghavendra K T

Cc: Eric B Munson
Cc: Avi Kivity
Cc: Marcelo Tosatti
Cc: Anthony Liguori
Cc: Jan Kiszka
Cc: "Andreas FÀrber"
---
Changes from V7:
  capabilty changed to KVM_CAP_KVMCLOCK_CTRL
  KVM_GUEST_PAUSED is pervcpu again
  CPUState renamed to CPUArchState


Thanks, change looks right to me.

Long-term I should probably consider supplying some cpu_foreach() macro
to iterate over them, but that would still need manual declaration of a
properly typed variable for the CPUArchState ->  CPUState switch.


  KVMCLOCK_GUEST_PAUSED changed to  KVM_KVMCLOCK_CTRL

Changes from V6:
  Remove unnecessary include

Changes from V5:
  KVM_GUEST_PAUSED is now a per vm ioctl instead of per vcpu

Changes from V4:
  Test if the guest paused capability is available before use

Changes from V3:
  Collapse new state change notification function into existsing function.
  Correct whitespace issues
  Change ioctl name to KVMCLOCK_GUEST_PAUSED
  Use for loop to iterate vpcu's

Changes from V2:
  Move ioctl into hw/kvmclock.c so as other arches can use it as it is
implemented

Changes from V1:
  Remove unnecessary encapsulating function
---

diff --git a/hw/kvm/clock.c b/hw/kvm/clock.c
index 446bd62..c8a34a5 100644
--- a/hw/kvm/clock.c
+++ b/hw/kvm/clock.c
@@ -64,10 +64,28 @@ static int kvmclock_post_load(void *opaque, int version_id)
  static void kvmclock_vm_state_change(void *opaque, int running,
   RunState state)
  {
+int ret;


Minor nitpick: We usually assign opaque values first thing in the
function, so maybe order ret last if you resend?


  KVMClockState *s = opaque;
+CPUArchState *penv = first_cpu;
+int cap_clock_ctrl = kvm_check_extension(kvm_state, KVM_CAP_KVMCLOCK_CTRL);

  if (running) {
  s->clock_valid = false;
+
+if (!cap_clock_ctrl) {
+return;
+}
+for (penv = first_cpu; penv != NULL; penv = penv->next_cpu) {
+ret = kvm_vcpu_ioctl(penv, KVM_KVMCLOCK_CTRL, 0);
+if (ret) {
+if (ret != -EINVAL) {
+fprintf(stderr,
+"kvmclock_vm_state_change: %s\n",
+strerror(-ret));


I always recommend to use __func__. Otherwise looks okay to me.

Andreas


+}
+return;
+}
+}
  }
  }




Thanks for Review. Sending with comments incorporated.
---
diff --git a/hw/kvm/clock.c b/hw/kvm/clock.c
index 446bd62..a6aa6e4 100644
--- a/hw/kvm/clock.c
+++ b/hw/kvm/clock.c
@@ -65,9 +65,27 @@ static void kvmclock_vm_state_change(void *opaque, 
int running,

  RunState state)
 {
 KVMClockState *s = opaque;
+CPUArchState *penv = first_cpu;
+int cap_clock_ctrl = kvm_check_extension(kvm_state, 
KVM_CAP_KVMCLOCK_CTRL);

+int ret;

 if (running) {
 s->clock_valid = false;
+
+if (!cap_clock_ctrl) {
+return;
+}
+for (penv = first_cpu; penv != NULL; penv = penv->next_cpu) {
+ret = kvm_vcpu_ioctl(penv, KVM_KVMCLOCK_CTRL, 0);
+if (ret) {
+if (ret != -EINVAL) {
+fprintf(stderr,
+" %s: %s\n", __FUNCTION__,
+strerror(-ret));
+}
+return;
+}
+}
 }
 }

Re: [Qemu-devel] [PATCH V8 1/1] Guest stop notificationorry for rduplicate mail

[Raghavendra K T]

On 04/06/2012 03:19 PM, Raghavendra K T wrote:

On 04/06/2012 02:29 PM, Andreas Färber wrote:

Am 06.04.2012 09:21, schrieb Raghavendra K T:

From: Eric B Munson

Often when a guest is stopped from the qemu console, it will report
spurious
soft lockup warnings on resume. There are kernel patches being
discussed that
will give the host the ability to tell the guest that it is being
stopped and
should ignore the soft lockup warning that generates. This patch uses
the qemu
Notifier system to tell the guest it is about to be stopped.

Signed-off-by: Eric B Munson
Signed-off-by: Raghavendra K T

Cc: Eric B Munson
Cc: Avi Kivity
Cc: Marcelo Tosatti
Cc: Anthony Liguori
Cc: Jan Kiszka
Cc: "Andreas FÀrber"
---
Changes from V7:
capabilty changed to KVM_CAP_KVMCLOCK_CTRL
KVM_GUEST_PAUSED is pervcpu again
CPUState renamed to CPUArchState


Thanks, change looks right to me.


I think I should have added Acked-by and resent full patch. So here is 
it. sorry for duplicate mail.

---
From: Eric B Munson 

Often when a guest is stopped from the qemu console, it will report spurious
soft lockup warnings on resume.  There are kernel patches being 
discussed that
will give the host the ability to tell the guest that it is being 
stopped and
should ignore the soft lockup warning that generates.  This patch uses 
the qemu

Notifier system to tell the guest it is about to be stopped.

Acked-by: "Andreas Färber" 
Signed-off-by: Eric B Munson 
Signed-off-by: Raghavendra K T 

Cc: Eric B Munson 
Cc: Avi Kivity 
Cc: Marcelo Tosatti 
Cc: Anthony Liguori 
Cc: Jan Kiszka 
Cc: "Andreas Färber" 
---
Changes from V7:
 capabilty changed to KVM_CAP_KVMCLOCK_CTRL
 KVM_GUEST_PAUSED is pervcpu again
 CPUState renamed to CPUArchState
 KVMCLOCK_GUEST_PAUSED changed to  KVM_KVMCLOCK_CTRL
 incorporated Andrea's comments (__FUNCTION__) etc

Changes from V6:
 Remove unnecessary include

Changes from V5:
 KVM_GUEST_PAUSED is now a per vm ioctl instead of per vcpu

Changes from V4:
 Test if the guest paused capability is available before use

Changes from V3:
 Collapse new state change notification function into existsing function.
 Correct whitespace issues
 Change ioctl name to KVMCLOCK_GUEST_PAUSED
 Use for loop to iterate vpcu's

Changes from V2:
 Move ioctl into hw/kvmclock.c so as other arches can use it as it is
implemented

Changes from V1:
 Remove unnecessary encapsulating function
---

diff --git a/hw/kvm/clock.c b/hw/kvm/clock.c
index 446bd62..a6aa6e4 100644
--- a/hw/kvm/clock.c
+++ b/hw/kvm/clock.c
@@ -65,9 +65,27 @@ static void kvmclock_vm_state_change(void *opaque, 
int running,

  RunState state)
 {
 KVMClockState *s = opaque;
+CPUArchState *penv = first_cpu;
+int cap_clock_ctrl = kvm_check_extension(kvm_state, 
KVM_CAP_KVMCLOCK_CTRL);

+int ret;

 if (running) {
 s->clock_valid = false;
+
+if (!cap_clock_ctrl) {
+return;
+}
+for (penv = first_cpu; penv != NULL; penv = penv->next_cpu) {
+ret = kvm_vcpu_ioctl(penv, KVM_KVMCLOCK_CTRL, 0);
+if (ret) {
+if (ret != -EINVAL) {
+fprintf(stderr,
+" %s: %s\n", __FUNCTION__,
+strerror(-ret));
+}
+return;
+}
+}
 }
 }

Re: [Qemu-devel] [PATCH V8 1/1] Guest stop notificationorry for rduplicate mail ndreas

[Raghavendra K T]

On 04/07/2012 02:39 AM, Andreas Färber wrote:

Am 06.04.2012 15:01, schrieb Raghavendra K T:

On 04/06/2012 03:19 PM, Raghavendra K T wrote:

On 04/06/2012 02:29 PM, Andreas Färber wrote:

Am 06.04.2012 09:21, schrieb Raghavendra K T:

From: Eric B Munson

Often when a guest is stopped from the qemu console, it will report
spurious
soft lockup warnings on resume. There are kernel patches being
discussed that
will give the host the ability to tell the guest that it is being
stopped and
should ignore the soft lockup warning that generates. This patch uses
the qemu
Notifier system to tell the guest it is about to be stopped.

Signed-off-by: Eric B Munson
Signed-off-by: Raghavendra K T

Cc: Eric B Munson
Cc: Avi Kivity
Cc: Marcelo Tosatti
Cc: Anthony Liguori
Cc: Jan Kiszka
Cc: "Andreas FÀrber"
---
Changes from V7:
capabilty changed to KVM_CAP_KVMCLOCK_CTRL
KVM_GUEST_PAUSED is pervcpu again
CPUState renamed to CPUArchState


Thanks, change looks right to me.


I think I should have added Acked-by and resent full patch. So here is
it. sorry for duplicate mail.


No, it was not intended as such since I can't ack the ioctl. Resends are
best done with git-send-email, i.e. a v9 with change log (whether as
reply or not, opinions are divided) to make sure the right version gets
applied in the end.


Ok. Thanks Andreas. sending V9 shortly




[...]

+if (ret) {
+if (ret != -EINVAL) {
+fprintf(stderr,
+" %s: %s\n", __FUNCTION__,


Is the whitespace before %s intentional? Wasn't there in v8.

The GCC manual recommends __func__, like I suggested, saying it's C99.
http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Function-Names.html#Function-Names
__FUNCTION__ usage is currently 432 vs. __func__ 579, so not wrong.



will correct them.


If you want to leave it that way you can add my

Reviewed-by: Andreas Färber

Andreas


+strerror(-ret));
+}
+return;
+}
+}
  }
  }

[Qemu-devel] [PATCH V9 1/1] Guest stop notification

[Raghavendra K T]

From: Eric B Munson 

Often when a guest is stopped from the qemu console, it will report spurious
soft lockup warnings on resume.  There are kernel patches being discussed that
will give the host the ability to tell the guest that it is being stopped and
should ignore the soft lockup warning that generates.  This patch uses the qemu
Notifier system to tell the guest it is about to be stopped.

Signed-off-by: Eric B Munson  
Signed-off-by: Raghavendra K T 

Cc: Eric B Munson 
Cc: Avi Kivity  
Cc: Marcelo Tosatti 
Cc: Anthony Liguori 
Cc: Jan Kiszka 
Cc: Andreas Färber 
---
Changes from V8:
 incorporated Andrea's comments: 
  use __func__ in place of actual function name 
  change ret variable order
  no whitespace before %s in fprintf   

Changes from V7:
 capabilty changed to KVM_CAP_KVMCLOCK_CTRL
 KVM_GUEST_PAUSED is pervcpu again
 CPUState renamed to CPUArchState
 KVMCLOCK_GUEST_PAUSED changed to  KVM_KVMCLOCK_CTRL

Changes from V6:
 Remove unnecessary include

Changes from V5:
 KVM_GUEST_PAUSED is now a per vm ioctl instead of per vcpu

Changes from V4:
 Test if the guest paused capability is available before use

Changes from V3:
 Collapse new state change notification function into existsing function.
 Correct whitespace issues
 Change ioctl name to KVMCLOCK_GUEST_PAUSED
 Use for loop to iterate vpcu's

Changes from V2:
 Move ioctl into hw/kvmclock.c so as other arches can use it as it is
implemented

Changes from V1:
 Remove unnecessary encapsulating function
---
not included Andreas's Reviewed by since used __func__ instead of __FUNCTION__
V8 of the patch was Reviewed-by: Andreas Färber 

diff --git a/hw/kvm/clock.c b/hw/kvm/clock.c
index 446bd62..824b978 100644
--- a/hw/kvm/clock.c
+++ b/hw/kvm/clock.c
@@ -65,9 +65,25 @@ static void kvmclock_vm_state_change(void *opaque, int 
running,
  RunState state)
 {
 KVMClockState *s = opaque;
+CPUArchState *penv = first_cpu;
+int cap_clock_ctrl = kvm_check_extension(kvm_state, KVM_CAP_KVMCLOCK_CTRL);
+int ret;
 
 if (running) {
 s->clock_valid = false;
+
+if (!cap_clock_ctrl) {
+return;
+}
+for (penv = first_cpu; penv != NULL; penv = penv->next_cpu) {
+ret = kvm_vcpu_ioctl(penv, KVM_KVMCLOCK_CTRL, 0);
+if (ret) {
+if (ret != -EINVAL) {
+fprintf(stderr, "%s: %s\n", __func__, strerror(-ret));
+}
+return;
+}
+}
 }
 }
 

[Qemu-devel] Qemu s390x emulation

[Suzuki K. Poulose]

Hi

I have been trying to setup a qemu session for qemu-system-s390x (on
x86_64) using a kernel (with initramfs built-in the kernel) without a
disk image. The kernel was built with s390 defconfig + disabled loadable
modules (just to keep everything inside the kernel).

$ qemu-system-s390x -M s390 -kernel vmlinux -m 1024


The session dies in say 2 secs, with an exit code of 0. I searched for
some hints / success stories, couldn't find any.

Am I doing something wrong here ? Please let me know the right procedure
for getting this up and running.


Thanks
Suzuki

Re: [Qemu-devel] Qemu s390x emulation

[Suzuki K. Poulose]

On 01/15/2013 04:39 PM, Alexander Graf wrote:


On 15.01.2013, at 12:05, Suzuki K. Poulose wrote:


Hi

I have been trying to setup a qemu session for qemu-system-s390x (on
x86_64) using a kernel (with initramfs built-in the kernel) without a
disk image. The kernel was built with s390 defconfig + disabled loadable
modules (just to keep everything inside the kernel).

$ qemu-system-s390x -M s390 -kernel vmlinux -m 1024


The session dies in say 2 secs, with an exit code of 0. I searched for
some hints / success stories, couldn't find any.

Am I doing something wrong here ? Please let me know the right procedure
for getting this up and running.


S390 boots using an "image" file. Please try -kernel /arch/s390/boot/image.

Tried that even, but not any better. btw, moved to the upstream git for 
qemu.


0
$/data/src/qemu/s390x-softmmu/qemu-system-s390x  -m 1024 -kernel ./image 
-nographic

$echo $?
0
$file ./image
./image: Linux S390

$ cd /data/src/qemu/ ; git log | head -n1
commit cf7c3f0cb5a7129f57fa9e69d410d6a05031988c

Thanks
Suzuki


Alex

[Qemu-devel] [PATCH 1/3] QEMU kvm: Syncing linux headers to 3.2.0-rc1

[Raghavendra K T]

 Update the kvm kernel headers to the 3.2.0-rc1 post using
scripts/update-linux-headers.sh script.

Signed-off-by: Raghavendra K T 
---
diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
index fb3fddc..08fe69e 100644
--- a/linux-headers/asm-powerpc/kvm.h
+++ b/linux-headers/asm-powerpc/kvm.h
@@ -149,6 +149,12 @@ struct kvm_regs {
 #define KVM_SREGS_E_UPDATE_DBSR(1 << 3)
 
 /*
+ * Book3S special bits to indicate contents in the struct by maintaining
+ * backwards compatibility with older structs. If adding a new field,
+ * please make sure to add a flag for that new field */
+#define KVM_SREGS_S_HIOR   (1 << 0)
+
+/*
  * In KVM_SET_SREGS, reserved/pad fields must be left untouched from a
  * previous KVM_GET_REGS.
  *
@@ -170,9 +176,11 @@ struct kvm_sregs {
} ppc64;
struct {
__u32 sr[16];
-   __u64 ibat[8];
-   __u64 dbat[8];
+   __u64 ibat[8]; 
+   __u64 dbat[8]; 
} ppc32;
+   __u64 flags; /* KVM_SREGS_S_ */
+   __u64 hior;
} s;
struct {
union {
@@ -292,41 +300,4 @@ struct kvm_allocate_rma {
__u64 rma_size;
 };
 
-struct kvm_book3e_206_tlb_entry {
-   __u32 mas8;
-   __u32 mas1;
-   __u64 mas2;
-   __u64 mas7_3;
-};
-
-struct kvm_book3e_206_tlb_params {
-   /*
-* For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV:
-*
-* - The number of ways of TLB0 must be a power of two between 2 and
-*   16.
-* - TLB1 must be fully associative.
-* - The size of TLB0 must be a multiple of the number of ways, and
-*   the number of sets must be a power of two.
-* - The size of TLB1 may not exceed 64 entries.
-* - TLB0 supports 4 KiB pages.
-* - The page sizes supported by TLB1 are as indicated by
-*   TLB1CFG (if MMUCFG[MAVN] = 0) or TLB1PS (if MMUCFG[MAVN] = 1)
-*   as returned by KVM_GET_SREGS.
-* - TLB2 and TLB3 are reserved, and their entries in tlb_sizes[]
-*   and tlb_ways[] must be zero.
-*
-* tlb_ways[n] = tlb_sizes[n] means the array is fully associative.
-*
-* KVM will adjust TLBnCFG based on the sizes configured here,
-* though arrays greater than 2048 entries will have TLBnCFG[NENTRY]
-* set to zero.
-*/
-   __u32 tlb_sizes[4];
-   __u32 tlb_ways[4];
-   __u32 reserved[8];
-};
-
-#define KVM_ONE_REG_PPC_HIOR   KVM_ONE_REG_PPC | 0x100
-
 #endif /* __LINUX_KVM_POWERPC_H */
diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
index 5df477a..b80420b 100644
--- a/linux-headers/asm-x86/hyperv.h
+++ b/linux-headers/asm-x86/hyperv.h
@@ -189,5 +189,6 @@
 #define HV_STATUS_INVALID_HYPERCALL_CODE   2
 #define HV_STATUS_INVALID_HYPERCALL_INPUT  3
 #define HV_STATUS_INVALID_ALIGNMENT4
+#define HV_STATUS_INSUFFICIENT_BUFFERS 19
 
 #endif
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index a8761d3..07bd557 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -371,6 +371,7 @@ struct kvm_s390_psw {
 #define KVM_S390_INT_VIRTIO0x2603u
 #define KVM_S390_INT_SERVICE   0x2401u
 #define KVM_S390_INT_EMERGENCY 0x1201u
+#define KVM_S390_INT_EXTERNAL_CALL 0x1202u
 
 struct kvm_s390_interrupt {
__u32 type;
@@ -556,8 +557,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_MAX_VCPUS 66   /* returns max vcpus per vm */
 #define KVM_CAP_PPC_HIOR 67
 #define KVM_CAP_PPC_PAPR 68
-#define KVM_CAP_SW_TLB 69
-#define KVM_CAP_ONE_REG 70
+#define KVM_CAP_S390_GMAP 71
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -637,49 +637,6 @@ struct kvm_clock_data {
__u32 pad[9];
 };
 
-#define KVM_MMU_FSL_BOOKE_NOHV 0
-#define KVM_MMU_FSL_BOOKE_HV   1
-
-struct kvm_config_tlb {
-   __u64 params;
-   __u64 array;
-   __u32 mmu_type;
-   __u32 array_len;
-};
-
-struct kvm_dirty_tlb {
-   __u64 bitmap;
-   __u32 num_dirty;
-};
-
-/* Available with KVM_CAP_ONE_REG */
-
-#define KVM_ONE_REG_GENERIC0xULL
-
-/*
- * Architecture specific registers are to be defined in arch headers and
- * ORed with the arch identifier.
- */
-#define KVM_ONE_REG_PPC0x1000ULL
-#define KVM_ONE_REG_X860x2000ULL
-#define KVM_ONE_REG_IA64   0x3000ULL
-#define KVM_ONE_REG_ARM0x4000ULL
-#define KVM_ONE_REG_S390   0x5000ULL
-
-struct kvm_one_reg {
-   __u64 id;
-   union {
-   __u8 reg8;
-  

[Qemu-devel] [PATCH 0/3] QEMU kvm: Adding KICK_VCPU capability to i386 kvm

[Raghavendra K T]

From: Raghavendra K T 

Three patch series following this, extends KVM-hypervisor
and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks.

PV ticket spinlock helps to solve Lock Holder Preemption problem discussed in
http://www.amd64.org/fileadmin/user_upload/pub/LHP-commented_slides.pdf.

When spinlock is contended,a guest vcpu relinqueshes cpu by halt().
Correspondingly, One hypercall is introduced in KVM hypervisor,that allows
a vcpu to kick the halted vcpu to continue with execution.

The series will : 
- Update qemu with latest linux header files (to 3.2.0-rc1).
- Enable KICK_VCPU capability in kvm/i386.

Raghavendra K T(3):
  Sync the linux headers to 3.2.0-rc1
  Sync the linux headers to patched linux kernel with 
KICK_VCPU capability.
  Add KICK_VCPU support in i386 target

---
The corresponding kernel patch is available in the thread
https://lkml.org/lkml/2011/11/30/62

[Qemu-devel] [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Raghavendra K T]

 Extend the KVM Hypervisor to enable KICK_VCPU feature that allows
a vcpu to kick the halted vcpu to continue with execution in PV ticket
spinlock.

Signed-off-by: Srivatsa Vaddagiri 
Signed-off-by: Raghavendra K T 
---
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 5bfc21f..69bce21 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -97,6 +97,7 @@ struct kvm_para_features {
 { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
 { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
 { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
+{ KVM_CAP_KICK_VCPU, KVM_FEATURE_KICK_VCPU },
 { -1, -1 }
 };
 

[Qemu-devel] [PATCH 2/3] QEMU kvm: Syncing linux headers to support KICK_VCPU capability

[Raghavendra K T]

Update the kernel header that adds a hypercall to support pv-ticketlocks.

Signed-off-by: Raghavendra K T 
---
diff --git a/linux-headers/asm-x86/kvm_para.h b/linux-headers/asm-x86/kvm_para.h
index f2ac46a..03d3a36 100644
--- a/linux-headers/asm-x86/kvm_para.h
+++ b/linux-headers/asm-x86/kvm_para.h
@@ -16,12 +16,14 @@
 #define KVM_FEATURE_CLOCKSOURCE0
 #define KVM_FEATURE_NOP_IO_DELAY   1
 #define KVM_FEATURE_MMU_OP 2
+
 /* This indicates that the new set of kvmclock msrs
  * are available. The use of 0x11 and 0x12 is deprecated
  */
 #define KVM_FEATURE_CLOCKSOURCE23
 #define KVM_FEATURE_ASYNC_PF   4
 #define KVM_FEATURE_STEAL_TIME 5
+#define KVM_FEATURE_KICK_VCPU  6
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 07bd557..47ab6ff 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_PPC_HIOR 67
 #define KVM_CAP_PPC_PAPR 68
 #define KVM_CAP_S390_GMAP 71
+#define KVM_CAP_KICK_VCPU 72
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/linux-headers/linux/kvm_para.h b/linux-headers/linux/kvm_para.h
index b315e27..e4a0e3e 100644
--- a/linux-headers/linux/kvm_para.h
+++ b/linux-headers/linux/kvm_para.h
@@ -19,6 +19,7 @@
 #define KVM_HC_MMU_OP  2
 #define KVM_HC_FEATURES3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE  4
+#define KVM_HC_KICK_CPU5
 
 /*
  * hypercalls use architecture specific

Re: [Qemu-devel] [RFC PATCH v2 2/3] utils: Add cpuinfo helper to fetch /proc/cpuinfo

[Suzuki K Poulose]

On 11/04/16 07:52, Vijay Kilari wrote:

Adding Suzuki Poulose.

Hi Suzuki,

On Fri, Apr 8, 2016 at 3:13 PM, Peter Maydell  wrote:

On 8 April 2016 at 07:21, Vijay Kilari  wrote:

On Thu, Apr 7, 2016 at 5:15 PM, Peter Maydell  wrote:

I'm told there are kernel patches in progress to get this sort
of information in a maintainable way to userspace, which are
currently somewhat stalled due to lack of anybody who wants to
consume it. If you have a use case then you should probably
flag it up with the kernel devs.


Can you please give references to those patches/discussion?


I'm told the most recent thread is https://lkml.org/lkml/2015/10/5/517
(and that most of the patches in that series have gone in, except
for the last 4 or 5 which implement the ABI).


Can you please throw some light on what is the status of ABI to
read cpu information in user space.
I wanted to know cpu implementer, part number in QEMU utils
to add prefetches to speed up live migration for Thunderx platform.



As for the patch series, except for that last 5 patches (which actually 
implements
the ABI), the infrastructure patches have been merged in v4.4.

We are awaiting feedback from possible consumers like toolchain (gcc, glibc).
If you think this will be suitable for you, thats good to know. There is
documentation available in the last patch in the above series. Could you please
try the series (on v4.4, which would be easier, by simply picking up the last
5 patches) and let us know if that works for you ?

Cheers
Suzuki

Re: [Qemu-devel] [RFC PATCH v2 2/3] utils: Add cpuinfo helper to fetch /proc/cpuinfo

[Suzuki K Poulose]

On 13/04/16 10:54, Vijay Kilari wrote:

On Mon, Apr 11, 2016 at 3:07 PM, Suzuki K Poulose
 wrote:

On 11/04/16 07:52, Vijay Kilari wrote:




Hi Suzuki,

  The last 5 patches are not compiling on v4.4. Looks like your patch
series is not merged completely. Can you please
rebase your patches and let me know.



Could you please give the tree below a try ?

git://linux-arm.org/linux-skp.git cpu-ftr/v3-4.3-rc4

Cheers
Suzuki

Re: [Qemu-devel] [RFC PATCH v2 2/3] utils: Add cpuinfo helper to fetch /proc/cpuinfo

[Suzuki K Poulose]

On 09/05/16 04:30, Vijay Kilari wrote:

Hi Suzuki,

   The last 5 patches are not compiling on v4.4. Looks like your patch
series is not merged completely. Can you please
rebase your patches and let me know.



Could you please give the tree below a try ?

git://linux-arm.org/linux-skp.git cpu-ftr/v3-4.3-rc4


This works.
Now the question is, Are your patches getting merged anytime soon?.


Well, we have been waiting for a use case, like this, before we merge
the series.

Will, Catalin,

Now that we have some real users of the infrastructure, what do you think ?
I can post an updated/rebased series, if you would like.


Suzuki




If not, I prefer to go with /proc/cpuinfo.

Another solution is look for /sys/devices/system/cpu/cpu$ID/identification/midr
if not available then fall back on /proc/cpuinfo.

Regards
Vijay

Re: [Qemu-devel] Virtual memory question

[C K Kashyap]

I am curious to know why you'd want to do it?

On Mon, Aug 9, 2010 at 2:03 AM, Dennis  wrote:

> Hi,
>
> I've been looking at the qemu source code but couldn't find anything
> that would suit my needs.
> Basically I'm looking for a way to use a file on disk as physical
> memory inside Qemu.
>
> Before I attempt to reinvent the wheel, has someone ever hacked in
> similar functionality and if so is there a diff patch available
> anywhere?
>
>


-- 
Regards,
Kashyap

[Qemu-devel] Running the user emulation

[C K Kashyap]

Hi,
I've built qemu on my mac osx using this config -
./configure --prefix=/Users/ckk/local/ --target-list="i386-softmmu
x86_64-softmmu" --enable-linux-user

Now, I have a simple a.out built on linux - how can I run it using qemu on
my mac box?

-- 
Regards,
Kashyap

Re: [Qemu-devel] Running the user emulation

[C K Kashyap]

Let me see if I understand this right -

qemu loads the a.out and begins to interpret the x86 instructions in the
a.out and when a system call happens, it makes the call the host system 
is that right?



On Wed, Aug 11, 2010 at 2:12 PM, Stefan Weil  wrote:

>  Am 11.08.2010 10:31, schrieb C K Kashyap:
>
> Hi,
> I've built qemu on my mac osx using this config -
> ./configure --prefix=/Users/ckk/local/ --target-list="i386-softmmu
> x86_64-softmmu" --enable-linux-user
>
> Now, I have a simple a.out built on linux - how can I run it using qemu on
> my mac box?
>
> --
> Regards,
> Kashyap
>
>
> Hi Kashyap,
>
> you cannot run it in user mode emulation unless you replace Mac OS by Linux
> on your mac box. Linux user emulations requires a Linux host.
>
> If you have a Linux host, you would need --target-list=i386-linux-user.
>
> You can run your a.out if you run system emulation (e.g. i386-softmmu/qemu)
> and install Linux there, of course.
>
> Regards,
> Stefan
>



-- 
Regards,
Kashyap

Re: [Qemu-devel] Running the user emulation

[C K Kashyap]

I was wondering if it would be easy to force build the user-emulation on mac
- as in, lets say my a.out from linux is really trivial - even statically
linked for that matter. All it does is, say, write "hello world\n" to the
screen - I'd imaging that write system call would be similar on mac (as far
as writing to stdout is concerned)  Would it be possible/easy to give it
a shot?


On Wed, Aug 11, 2010 at 2:48 PM, Stefan Weil  wrote:

>  Am 11.08.2010 11:06, schrieb C K Kashyap:
>
> Let me see if I understand this right -
>
> qemu loads the a.out and begins to interpret the x86 instructions in the
> a.out and when a system call happens, it makes the call the host system 
> is that right?
>
>
>
> Right. That's the way how linux user mode emulation (for example qemu-i386)
> works.
> See linux-user/syscall.c if you want to see more details.
>
> bsd-user and darwin-user are also supported (more or less), but darwin-user
> only supports translation of darwin/powerpc to darwin/x86 syscalls.
> It won't help you to run a linux a.out on your mac.
>
>
>
>
> On Wed, Aug 11, 2010 at 2:12 PM, Stefan Weil  wrote:
>
> Am 11.08.2010 10:31, schrieb C K Kashyap:
>
> Hi,
> I've built qemu on my mac osx using this config -
> ./configure --prefix=/Users/ckk/local/ --target-list="i386-softmmu
> x86_64-softmmu" --enable-linux-user
>
> Now, I have a simple a.out built on linux - how can I run it using qemu on
> my mac box?
>
> --
> Regards,
> Kashyap
>
>
> Hi Kashyap,
>
> you cannot run it in user mode emulation unless you replace Mac OS by Linux
> on your mac box. Linux user emulations requires a Linux host.
>
> If you have a Linux host, you would need --target-list=i386-linux-user.
>
> You can run your a.out if you run system emulation (e.g. i386-softmmu/qemu)
> and install Linux there, of course.
>
> Regards,
> Stefan
>
>
>
>
> --
> Regards,
> Kashyap
>
>
>


-- 
Regards,
Kashyap

Re: [Qemu-devel] Running the user emulation

[C K Kashyap]

Thanks Stefan for the explanation ... It does not look like a pleasant thing
to do though :)

On Wed, Aug 11, 2010 at 3:33 PM, Stefan Weil  wrote:

>  Am 11.08.2010 11:33, schrieb C K Kashyap:
>
> I was wondering if it would be easy to force build the user-emulation on
> mac - as in, lets say my a.out from linux is really trivial - even
> statically linked for that matter. All it does is, say, write "hello
> world\n" to the screen - I'd imaging that write system call would be similar
> on mac (as far as writing to stdout is concerned)  Would it be
> possible/easy to give it a shot?
>
>
>
> It should be possible. Projects like wine can emulate windows system calls
> on linux.
> Emulating darwin system calls on linux is much easier.
>
> If you want to try it yourself, you could start by removing the exit from
> file configure:
>
> if test "$linux" != "yes" ; then
>   echo "ERROR: Target '$target' is only available on a Linux host"
>   # exit 1
> fi
>
> Then you can run 'configure --target-list=i386-linux-user'.
> Run make and fix all error messages which you will get.
> If you think they are in code which you don't need for your a.out,
> #if 0 ... #endif helps to remove that code.
>
> Run the new-built qemu-i386 with your a.out and fix the remaining bugs.
>
> That's all :-)
>
>
>  On Wed, Aug 11, 2010 at 2:48 PM, Stefan Weil wrote:
>
> Am 11.08.2010 11:06, schrieb C K Kashyap:
>
> Let me see if I understand this right -
>
> qemu loads the a.out and begins to interpret the x86 instructions in the
> a.out and when a system call happens, it makes the call the host system 
> is that right?
>
>
>
>  Right. That's the way how linux user mode emulation (for example
> qemu-i386) works.
> See linux-user/syscall.c if you want to see more details.
>
> bsd-user and darwin-user are also supported (more or less), but darwin-user
> only supports translation of darwin/powerpc to darwin/x86 syscalls.
> It won't help you to run a linux a.out on your mac.
>
>
>
>
>  On Wed, Aug 11, 2010 at 2:12 PM, Stefan Weil wrote:
>
> Am 11.08.2010 10:31, schrieb C K Kashyap:
>
> Hi,
> I've built qemu on my mac osx using this config -
> ./configure --prefix=/Users/ckk/local/ --target-list="i386-softmmu
> x86_64-softmmu" --enable-linux-user
>
> Now, I have a simple a.out built on linux - how can I run it using qemu on
> my mac box?
>
> --
> Regards,
> Kashyap
>
>
> Hi Kashyap,
>
> you cannot run it in user mode emulation unless you replace Mac OS by Linux
> on your mac box. Linux user emulations requires a Linux host.
>
> If you have a Linux host, you would need --target-list=i386-linux-user.
>
> You can run your a.out if you run system emulation (e.g. i386-softmmu/qemu)
> and install Linux there, of course.
>
> Regards,
> Stefan
>
>  --
> Regards,
> Kashyap
>
>   --
> Regards,
> Kashyap
>
>
>


-- 
Regards,
Kashyap

Re: [Qemu-devel] Running the user emulation

[C K Kashyap]

You mean qemu on NetBSD or NetBSD in general - if so, I know that even
Solaris can also execute linux binaries. And to do it, it would require me
to modify the mac os - which I have no clue how to.

Maybe I'll try out what Stefan said - although, on the face of it, it looks
like an endless cycles of makefile fixes - it might just turn out to be
easy.

The idea is that, qemu already knows how to load up the elf etc .. and has
the engine to execute x86 instructions  all that's required is to
provide an infrastructure that imitates linux's system calls.

On Thu, Aug 12, 2010 at 12:08 AM, Natalia Portillo wrote:

> You can check how NetBSD does that.
>
> NetBSD is able to run executables from other UNIXes and POSIX-compatible
> systems, including, Linux, IRIX, Darwin.
> They do that with a series of syscall conversions and library
> substitutions.
>
> That should be portable to use Mac OS X as host instead of NetBSD, and to
> run thru QEMU (running x86 Linux software on PowerPC Darwin)
>
> Regards,
> Natalia Portillo
>
> El 11/08/2010, a las 10:33, C K Kashyap escribió:
>
> I was wondering if it would be easy to force build the user-emulation on
> mac - as in, lets say my a.out from linux is really trivial - even
> statically linked for that matter. All it does is, say, write "hello
> world\n" to the screen - I'd imaging that write system call would be similar
> on mac (as far as writing to stdout is concerned)  Would it be
> possible/easy to give it a shot?
>
>
> On Wed, Aug 11, 2010 at 2:48 PM, Stefan Weil  wrote:
>
>>  Am 11.08.2010 11:06, schrieb C K Kashyap:
>>
>> Let me see if I understand this right -
>>
>> qemu loads the a.out and begins to interpret the x86 instructions in the
>> a.out and when a system call happens, it makes the call the host system 
>> is that right?
>>
>>
>>
>> Right. That's the way how linux user mode emulation (for example
>> qemu-i386) works.
>> See linux-user/syscall.c if you want to see more details.
>>
>> bsd-user and darwin-user are also supported (more or less), but
>> darwin-user
>> only supports translation of darwin/powerpc to darwin/x86 syscalls.
>> It won't help you to run a linux a.out on your mac.
>>
>>
>>
>>
>> On Wed, Aug 11, 2010 at 2:12 PM, Stefan Weil wrote:
>>
>> Am 11.08.2010 10:31, schrieb C K Kashyap:
>>
>> Hi,
>> I've built qemu on my mac osx using this config -
>> ./configure --prefix=/Users/ckk/local/ --target-list="i386-softmmu
>> x86_64-softmmu" --enable-linux-user
>>
>> Now, I have a simple a.out built on linux - how can I run it using qemu on
>> my mac box?
>>
>> --
>> Regards,
>> Kashyap
>>
>>
>> Hi Kashyap,
>>
>> you cannot run it in user mode emulation unless you replace Mac OS by
>> Linux
>> on your mac box. Linux user emulations requires a Linux host.
>>
>> If you have a Linux host, you would need --target-list=i386-linux-user.
>>
>> You can run your a.out if you run system emulation (e.g.
>> i386-softmmu/qemu)
>> and install Linux there, of course.
>>
>> Regards,
>> Stefan
>>
>>
>>
>>
>> --
>> Regards,
>> Kashyap
>>
>>
>>
>
>
> --
> Regards,
> Kashyap
>
>
>


-- 
Regards,
Kashyap

[Qemu-devel] OS with only segmentation - will it be faster?

[C K Kashyap]

Hi,
This is not strictly qemu related but I think people who have a good idea
about it must be on this list.
I was wondering if I had an app that requires a fixed quantity of memory -
sufficiently less than the available physical memory. Would it benefit from
getting rid of the paging mechanism in the OS/hardware?
As in, since the number of tasks are also fixed - we'd use only segmentation
to partition the VM area? Would eliminating the paging layer give good
returns?

-- 
Regards,
Kashyap

Re: [Qemu-devel] OS with only segmentation - will it be faster?

[C K Kashyap]

Thanks Malc .. I'll check out the video ... and perhaps ping you off the
list.


On Fri, Aug 13, 2010 at 10:15 AM, malc  wrote:

> On Fri, 13 Aug 2010, C K Kashyap wrote:
>
> > Hi,
> > This is not strictly qemu related but I think people who have a good idea
> > about it must be on this list.
> > I was wondering if I had an app that requires a fixed quantity of memory
> -
> > sufficiently less than the available physical memory. Would it benefit
> from
> > getting rid of the paging mechanism in the OS/hardware?
> > As in, since the number of tasks are also fixed - we'd use only
> segmentation
> > to partition the VM area? Would eliminating the paging layer give good
> > returns?
> >
>
> Microsoft researchers working on Singularity claimed[1] that it does
> provide significant speed improvements, and recent (few days ago)
> discussion on comp.arch suggested as much (no need to go though TLB).
>
> [1]
> http://channel9.msdn.com/shows/Going+Deep/Singularity-A-research-OS-written-in-C/
>(maybe the claim was made in some other video, in any case it should
> be there on Channel 9)
>
> --
> mailto:av1...@comtv.ru
>



-- 
Regards,
Kashyap

[Qemu-devel] qemu user mode emulation / callgraph

[C K Kashyap]

Hi
I was wondering if qemu's user mode emulation could be tweaked to generate
callgraph.

Today was the first time I tried the user mode emulation - I ran into the
below issue

[u...@kashyap lab]$ qemu-x86_64 -cpu qemu64 ./a.out
ERROR: ioctl(SNDCTL_DSP_MAPINBUF): target=0x80085013 host=0x80105013
ERROR: ioctl(SNDCTL_DSP_MAPOUTBUF): target=0x80085014 host=0x80105014
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

I'd appreciate any help.

-- 
Regards,
Kashyap

[Qemu-devel] Build error - target i386-linux-user on RHEL4.8 x86_64

[C K Kashyap]

Hi,
I tried to build qemu's user mode linux emulation on RHEL 4.8 x86_64 -
but I run into this issue -
  ARi386-linux-user/libqemu.a
  LINK  i386-linux-user/qemu-i386
/usr/bin/ld:/home/ckk/lab/qemu-0.12.5/x86_64.ld:41: syntax error
collect2: ld returned 1 exit status
make[1]: *** [qemu-i386] Error 1
make: *** [subdir-i386-linux-user] Error 2
[...@windowher-dr qemu-0.12.5]$


This was from qemu-0.12.5.

I am however, able to build qemu-0.11.1 correctly.

I'd really appreciate it if someone could help me with the build error.

-- 
Regards,
Kashyap

[Qemu-devel] USB-UHCI skipping frames from the frame list

[Althaf K Backer]

Given below is the debug o/p from usb-uhci,strangely it seems to
skip the frames after 118 it jumps to 145  .. similar is the
case with frame 0 , it doesn't load frame 0 rather jumps to
frame 1.The guest is minix 3.1.5 and the o/p was generated
from the driver under development,i have notice the same
behavior with NetBSD

uhci: new frame #117
uhci: processing frame 117 addr 0x125251d4
uhci: TD 0x11cc02a0 load. link 0x125272a2 ctrl 0x200 token 0x0 qh 0x0
uhci: TD 0x11cc02a0 skip. link 0x125272a2 ctrl 0x200 token 0x0 qh 0x0
uhci: QH 0x125272a2 load. link 0x12529002 elink 0x1
uhci: QH 0x12529002 load. link 0x12528002 elink 0x1
uhci: QH 0x12528002 load. link 0x12526002 elink 0x1
uhci: QH 0x12526002 load. link 0x1 elink 0x11cc1000
uhci: TD 0x11cc1000 load. link 0x1 ctrl 0x0 token 0x0 qh 0x12526002
uhci: TD 0x11cc1000 skip. link 0x1 ctrl 0x0 token 0x0 qh 0x12526002
uhci: new frame #118
uhci: processing frame 118 addr 0x125251d8
uhci: TD 0x11cc02c0 load. link 0x125272c2 ctrl 0x200 token 0x0 qh 0x0
uhci: TD 0x11cc02c0 skip. link 0x125272c2 ctrl 0x200 token 0x0 qh 0x0
uhci: QH 0x125272c2 load. link 0x12529002 elink 0x1
uhci: new frame #145
uhci: processing frame 145 addr 0x12525244
uhci: TD 0x11cc0220 load. link 0x12527222 ctrl 0x200 token 0x0 qh 0x0
uhci: TD 0x11cc0220 skip. link 0x12527222 ctrl 0x200 token 0x0 qh 0x0
uhci: QH 0x12527222 load. link 0x12529002 elink 0x1
uhci: QH 0x12529002 load. link 0x12528002 elink 0x1
uhci: QH 0x12528002 load. link 0x12526002 elink 0x1
uhci: QH 0x12526002 load. link 0x1 elink 0x11cc1000
uhci: TD 0x11cc1000 load. link 0x1 ctrl 0x0 token 0x0 qh 0x12526002
uhci: TD 0x11cc1000 skip. link 0x1 ctrl 0x0 token 0x0 qh 0x12526002
uhci: new frame #146
uhci: processing frame 146 addr 0x12525248

[Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM

[Nikolai K. Bochev]

Hello,

I am getting the following error trying to compile sheepdog on Ubuntu 9.10 ( 
2.6.31-14 x64 ) :

cd shepherd; make
make[1]: Entering directory `/home/shiny/Packages/sheepdog-2009102101/shepherd'
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE shepherd.c -o 
shepherd.o
shepherd.c: In function ‘main’:
shepherd.c:300: warning: dereferencing pointer ‘hdr.55’ does break 
strict-aliasing rules
shepherd.c:300: note: initialized from here
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE treeview.c -o 
treeview.o
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE 
../lib/event.c -o ../lib/event.o
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE ../lib/net.c 
-o ../lib/net.o
../lib/net.c: In function ‘write_object’:
../lib/net.c:358: warning: ‘vosts’ may be used uninitialized in this function
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE 
../lib/logger.c -o ../lib/logger.o
cc shepherd.o treeview.o ../lib/event.o ../lib/net.o ../lib/logger.o -o 
shepherd -lncurses -lcrypto
make[1]: Leaving directory `/home/shiny/Packages/sheepdog-2009102101/shepherd'
cd sheep; make
make[1]: Entering directory `/home/shiny/Packages/sheepdog-2009102101/sheep'
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE sheep.c -o 
sheep.o
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE store.c -o 
store.o
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE net.c -o net.o
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE work.c -o 
work.o
In file included from /usr/include/asm/fcntl.h:1,
 from /usr/include/linux/fcntl.h:4,
 from /usr/include/linux/signalfd.h:13,
 from work.c:31:
/usr/include/asm-generic/fcntl.h:117: error: redefinition of ‘struct flock’
/usr/include/asm-generic/fcntl.h:140: error: redefinition of ‘struct flock64’
make[1]: *** [work.o] Error 1
make[1]: Leaving directory `/home/shiny/Packages/sheepdog-2009102101/sheep'
make: *** [all] Error 2

I have all the required libs installed. Patching and compiling qemu-kvm went 
flawless.

- Original Message -
From: "MORITA Kazutaka" 
To: k...@vger.kernel.org, qemu-devel@nongnu.org, linux-fsde...@vger.kernel.org
Sent: Wednesday, October 21, 2009 8:13:47 AM
Subject: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM

Hi everyone,

Sheepdog is a distributed storage system for KVM/QEMU. It provides
highly available block level storage volumes to VMs like Amazon EBS.
Sheepdog supports advanced volume management features such as snapshot,
cloning, and thin provisioning. Sheepdog runs on several tens or hundreds
of nodes, and the architecture is fully symmetric; there is no central
node such as a meta-data server.

The following list describes the features of Sheepdog.

 * Linear scalability in performance and capacity
 * No single point of failure
 * Redundant architecture (data is written to multiple nodes)
 - Tolerance against network failure
 * Zero configuration (newly added machines will join the cluster 
automatically)
 - Autonomous load balancing
 * Snapshot
 - Online snapshot from qemu-monitor
 * Clone from a snapshot volume
 * Thin provisioning
 - Amazon EBS API support (to use from a Eucalyptus instance)

(* = current features, - = on our todo list)

More details and download links are here:

http://www.osrg.net/sheepdog/

Note that the code is still in an early stage.
There are some critical TODO items:

 - VM image deletion support
 - Support architectures other than X86_64
 - Data recoverys
 - Free space management
 - Guarantee reliability and availability under heavy load
 - Performance improvement
 - Reclaim unused blocks
 - More documentation

We hope finding people interested in working together.
Enjoy!


Here are examples:

- create images

$ kvm-img create -f sheepdog "Alice's Disk" 256G
$ kvm-img create -f sheepdog "Bob's Disk" 256G

- list images

$ shepherd info -t vdi
4 : Alice's Disk  256 GB (allocated: 0 MB, shared: 0 MB), 2009-10-15
16:17:18, tag:0, current
8 : Bob's Disk256 GB (allocated: 0 MB, shared: 0 MB), 2009-10-15
16:29:20, tag:0, current

- start up a virtual machine

$ kvm --drive format=sheepdog,file="Alice's Disk"

- create a snapshot

$ kvm-img snapshot -c name sheepdog:"Alice's Disk"

- clone from a snapshot

$ kvm-img create -b sheepdog:"Alice's Disk":0 -f sheepdog "Charlie's Disk"


Thanks.

-- 
MORITA, Kazutaka

NTT Cyber Space Labs
OSS Computing Project
Kernel Group
E-mail: morita.kazut...@lab.ntt.co.jp

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

[Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM

[Nikolai K. Bochev]

Hello, 

when i try to compile, i'm getting the following error ( Using ubuntu 9.10, x64 
) : 

cd shepherd; make 
make[1]: Entering directory `/home/shiny/Packages/sheepdog-2009102101/shepherd' 
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE shepherd.c -o 
shepherd.o 
shepherd.c: In function ‘main’: 
shepherd.c:300: warning: dereferencing pointer ‘hdr.55’ does break 
strict-aliasing rules 
shepherd.c:300: note: initialized from here 
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE treeview.c -o 
treeview.o 
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE 
../lib/event.c -o ../lib/event.o 
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE ../lib/net.c 
-o ../lib/net.o 
../lib/net.c: In function ‘write_object’: 
../lib/net.c:358: warning: ‘vosts’ may be used uninitialized in this function 
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE 
../lib/logger.c -o ../lib/logger.o 
cc shepherd.o treeview.o ../lib/event.o ../lib/net.o ../lib/logger.o -o 
shepherd -lncurses -lcrypto 
make[1]: Leaving directory `/home/shiny/Packages/sheepdog-2009102101/shepherd' 
cd sheep; make 
make[1]: Entering directory `/home/shiny/Packages/sheepdog-2009102101/sheep' 
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE sheep.c -o 
sheep.o 
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE store.c -o 
store.o 
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE net.c -o 
net.o 
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE work.c -o 
work.o 
In file included from /usr/include/asm/fcntl.h:1, 
from /usr/include/linux/fcntl.h:4, 
from /usr/include/linux/signalfd.h:13, 
from work.c:31: 
/usr/include/asm-generic/fcntl.h:117: error: redefinition of ‘struct flock’ 
/usr/include/asm-generic/fcntl.h:140: error: redefinition of ‘struct flock64’ 
make[1]: *** [work.o] Error 1 
make[1]: Leaving directory `/home/shiny/Packages/sheepdog-2009102101/sheep' 
make: *** [all] Error 2 

The qemu-kvm source with patched support for sheepdog compiles fine. 

- Original Message - 
From: "MORITA Kazutaka"  
To: k...@vger.kernel.org, qemu-devel@nongnu.org, linux-fsde...@vger.kernel.org 
Sent: Wednesday, October 21, 2009 8:13:47 AM 
Subject: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM 

Hi everyone, 

Sheepdog is a distributed storage system for KVM/QEMU. It provides 
highly available block level storage volumes to VMs like Amazon EBS. 
Sheepdog supports advanced volume management features such as snapshot, 
cloning, and thin provisioning. Sheepdog runs on several tens or hundreds 
of nodes, and the architecture is fully symmetric; there is no central 
node such as a meta-data server. 

The following list describes the features of Sheepdog. 

* Linear scalability in performance and capacity 
* No single point of failure 
* Redundant architecture (data is written to multiple nodes) 
- Tolerance against network failure 
* Zero configuration (newly added machines will join the cluster automatically) 
- Autonomous load balancing 
* Snapshot 
- Online snapshot from qemu-monitor 
* Clone from a snapshot volume 
* Thin provisioning 
- Amazon EBS API support (to use from a Eucalyptus instance) 

(* = current features, - = on our todo list) 

More details and download links are here: 

http://www.osrg.net/sheepdog/ 

Note that the code is still in an early stage. 
There are some critical TODO items: 

- VM image deletion support 
- Support architectures other than X86_64 
- Data recoverys 
- Free space management 
- Guarantee reliability and availability under heavy load 
- Performance improvement 
- Reclaim unused blocks 
- More documentation 

We hope finding people interested in working together. 
Enjoy! 


Here are examples: 

- create images 

$ kvm-img create -f sheepdog "Alice's Disk" 256G 
$ kvm-img create -f sheepdog "Bob's Disk" 256G 

- list images 

$ shepherd info -t vdi 
4 : Alice's Disk 256 GB (allocated: 0 MB, shared: 0 MB), 2009-10-15 
16:17:18, tag: 0, current 
8 : Bob's Disk 256 GB (allocated: 0 MB, shared: 0 MB), 2009-10-15 
16:29:20, tag: 0, current 

- start up a virtual machine 

$ kvm --drive format=sheepdog,file="Alice's Disk" 

- create a snapshot 

$ kvm-img snapshot -c name sheepdog:"Alice's Disk" 

- clone from a snapshot 

$ kvm-img create -b sheepdog:"Alice's Disk":0 -f sheepdog "Charlie's Disk" 


Thanks. 

-- 
MORITA, Kazutaka 

NTT Cyber Space Labs 
OSS Computing Project 
Kernel Group 
E-mail: morita.kazut...@lab.ntt.co.jp 

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

[Qemu-devel] eabi support for arm?

[K. Richard Pixley]

Can anyone tell me if there's any work going on to support eabi for arm?

--rich



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [RFC] Allow trying to boot from multiple devices

[K. Richard Pixley]

Jeremy Katz wrote:


The bochs rombios has supported attempting to boot from more than one
device for a while.  It seems like it would make sense to be able to
specify "-boot acd" as an argument for qemu to try booting first from
the floppy, then the cd and finally the hard drive to make things more
like a "real" machine.  Does this seem reasonable?

It would make some things like installing guests, (which tend to want to 
reboot from the hard disk they've just populated from 
ether/cd/dvd/whatever), easier.


--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Are the new arm targets working?

[K. Richard Pixley]

Are the new arm targets, versatile[ap]b expected to be working?

On ubuntu-5, building 0.8.2 yields a binary which can run the other two 
targets, but which hangs after printing the monitor prompt on either of 
these.


--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Are the new arm targets working?

[K. Richard Pixley]

Are the new arm targets, versatile[ap]b expected to be working?

On ubuntu-5, building 0.8.2 yields a binary which can run the other two
targets, but which hangs after printing the monitor prompt on either of
these.

--rich
(apologies if you see this twice.  I thought I sent it yesterday, but I 
didn't see it echoed back.)



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Are the new arm targets working?

[K. Richard Pixley]

Are the new arm targets, versatile[ap]b expected to be working?

On ubuntu-5, building 0.8.2 yields a binary which can run the other two
targets, but which hangs after printing the monitor prompt on either of
these.

--rich
(apologies if you see this twice.  I thought I sent it last week, but I
didn't see it echoed back.)


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Are the new arm targets working?

[K. Richard Pixley]

Are the new arm targets, versatile[ap]b expected to be working?

On ubuntu-5, building 0.8.2 yields a binary which can run the other two
targets, but which hangs after printing the monitor prompt on either of
these.

--rich
(apologies if you see this multiple times.  I thought I sent it 
previously, but I didn't see it echoed back.)



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] ARM CPU Speed simulated by Qemu?

[K. Richard Pixley]

I have at least one 450Mhz k6 in my spare bedroom.  I'll by happy to 
sell it to you as a platform for running debian and qemu.  I'm sure it's 
performance would be lower than most of the current amd processors, 
though it might not be slower than some of the current intel chips, 
(*grin*).


--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu & arm eabi (armel)

[K. Richard Pixley]

Does anyone have qemu running in user emulation with arm eabi, (armel), 
traps?


I can get qemu-system booting an armel system.  And I can get qemu-user 
running with the codesourcery gcc-3 eabi libc's, (ie, the ones with the 
codesourcery kernel call "shims"), but I haven't gotten it working yet 
with eabi kernel calls in user mode.


Should this be expected to work in 0.8.2?

--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu & arm eabi (armel)

[K. Richard Pixley]

Ok, then I'm confused because I'm seeing dumps just trying to run a null 
program.  Unless there's NPTL setup stuff in crt0, I can't guess what 
might be going on yet.  This same null binary runs on a qemu-system with 
suitable rootfs & kernel.


--rich

[EMAIL PROTECTED]> ./qemu-arm --version
qemu-arm version 0.8.2, Copyright (c) 2003-2005 Fabrice Bellard
[...]
[EMAIL PROTECTED]> ./qemu-arm ./null
qemu: uncaught target signal 11 (Segmentation fault) - exiting



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu & arm eabi (armel)

[K. Richard Pixley]

Paul Brook wrote:

  On Tuesday 26 September 2006 23:14, K. Richard Pixley wrote:
  
  
Ok, then I'm confused because I'm seeing dumps just trying to run a null
program.  Unless there's NPTL setup stuff in crt0, I can't guess what
might be going on yet.  This same null binary runs on a qemu-system with
suitable rootfs & kernel.

  
  The glibc startup code contains TLS initialisation that will fail on unpatched 
qemu. If you have applied the TLS patch there are a couple of other things 
that could cause problems:

- Make sure it's picking up the correct target shared libraries (or link your 
test application statically).
  

Done.

  - Try configuring qemu with --static. The default (building qemu as a shared 
library) seems to cause strange problems on many systems.
  

Done.

  - Make sure uname -r reports at least 2.6.16 (qemu can lie for you).
  

Ah.  Hm..  ubuntu-5 is currently:

[EMAIL PROTECTED]> uname -a
Linux svrpixleylnx 2.6.12-10-686-smp #1 SMP Tue Jul 18 23:03:01 UTC
2006 i686 GNU/Linux

Do you know why 2.6.16 would be required?  (I'll see if I can't
find/build a 2.6.16 system on which to try it today.)

--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu & arm eabi (armel)

[K. Richard Pixley]

Paul Brook wrote:

  
Do you know why 2.6.16 would be required?  (I'll see if I can't
find/build a 2.6.16 system on which to try it today.)

  
  Because arm-linux didn't get EABI support until 2.6.16 (though our toolchains 
may accept 2.6.14). glibc has santity checks stop applications even trying to 
run on kernels that are too old.

As I mentioned qemu lie about the kernel version. See -r 
and --enable-uname-release.

I'm confused.  My host kernel, (hosted on an x86 ubuntu box), is:

[EMAIL PROTECTED]> uname -r
2.6.12-10-686-smp

And my understanding is that there is no kernel when running qemu-user
because qemu is emulating the kernel calls.

What am I missing?  Or where does the kernel version come into play?

--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu-arm is a shared library?

[K. Richard Pixley]

When I build qemu-0.8.2, qemu-arm is a shared library rather than being 
an executable.  This seems highly suspicious and makes it particularly 
difficult to debug.  What's the rationale behind this?


--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu-arm user mode

[K. Richard Pixley]

I have now managed to run a null program and a helloworld, (both eabi, 
linked statically, and without any thread calls), using the qemu-arm 
user mode, both inside and outside of scratchbox.  To do this with 
qemu-0.8.2 I needed the following:


1) Paul's patch for NLS.  
http://lists.gnu.org/archive/html/qemu-devel/2006-09/msg00194.html  Note 
that you will need to remove your object directory, reconfigure, and 
rebuild after patching.  The patch changes configuration data which will 
not be updated from a simple rebuild so you will need to remove your 
object and reconfigure before building again.  I didn't notice and this 
held me up for several days.


2) to build a qemu that can be debugged, you'll need to build it 
statically.  To do this, you can configure qemu using "--static".


3) qemu cannot be built with gcc-4, (due to a problem I don't 
understand), nor with gcc-3 using -O0, (due to an apparent collision 
between register allocation and inlining).  You'll need to use a gcc-3, 
with at least -O1 if you want to debug.  I changed the -O values by 
editing the Makefiles directly, but this change isn't really necessary 
if you don't plan to debug qemu.


4) Configure using "--enable-uname-revision=2.6.16".  Paul partially 
explained this recently.  Glibc, (the one your target program linked 
against when it was compiled), runs a check to see what kernel version 
it's running over.  When qemu-user emulates this call, by default, it 
asks the underlying host kernel what version the underlying host kernel 
is and then tells gdb that the emulated kernel version is the same.


While there's an argument that this is reasonable, in the case of arm 
eabi, it's a problem for many people.  Since eabi support was only added 
to the kernel in 2.6.16, earlier kernels can't handle eabi kernel 
calls.  Glibc knows this and will fail out if it believes itself to be 
running on an older kernel.  The fix, then, is to either run qemu-arm 
with the command line option, "-r 2.6.16" or to configure using 
"--enable-uname-revision=2.6.16" which will ask qemu to simply report 
these version numbers rather than querying the underlying host kernel.  
(Note: if your underlying (x86) host kernel happens to be 2.6.16 or 
later, then you probably don't need this workaround.)


None of these are new issues or fixes.  It just took me a few days to 
collect, run into them, and sort through them all.  So I'm posting my 
results here.


--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu-arm user mode

[K. Richard Pixley]

Paul Brook wrote:

1) Paul's patch for NLS.


You mean TLS and/or NPTL. NLS is something completely different :-)
Bah.  Of course you're right.  And I'm sure you can explain your patch 
better than I can.


--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu-system-sparc question?

[K. Richard Pixley]

Ishwar Rattan wrote:

Is it possible to boot the iso image
  debian-31r3-sparc-netinst.iso

in qemu-system-sparc? What about other
Linux distributions? 

I haven't tried it.  But I'd be curious to hear how it works for you.

--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu-system-sparc question?

[K. Richard Pixley]

Blue Swirl wrote:
BTW, we could easily design and implement an ideal CPU just for Qemu 
purposes. It could be unlike any existing hardware, for example with 
zero or thousands of registers. The problem would be making a compiler 
for the CPU, also porting some OS to it. Any GCC and Linux guru 
volunteers? CS research projects? 
This idea has been around for a long time.  When I was in school, one of 
our projects was to build a processor for such an architecture.  The 
idea has been kicked around the gnu development toolchain community for 
some time as well.


Gcc is sexy.  You shouldn't have any trouble finding a student or 
another volunteer who's interested in implementing a simple, relatively 
orthogonal instruction set.


Gas is harder.  It's not so sexy.  Nor is ld, nor gdb.

Porting linux at that point is pretty much just a matter of determining 
cpu start and load addresses.


Note: mmu management would also be a modest task, either to implement or 
to circumvent.


--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu-system-sparc question?

[K. Richard Pixley]

Johannes Schindelin wrote:

This s reminds me of Java.

Or lisp.

:-).

--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu vs gcc4

[K. Richard Pixley]

Could someone please explain the issue with gcc4, please?  Or point me 
to an existing explanation?


I mean, I understand that qemu is believed to be building incorrectly 
with gcc4.  But what is the failure mode folks have been seeing?  And 
what's being done about it or what needs to be done about it?  Is this 
an issue for all targets or is it x86 specific?


Thanks,
--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu vs gcc4

[K. Richard Pixley]

Martin Guy wrote:

Now, gcc4 can produce code with several return instructions (with no
option to turn that of, as far as I understand). You cannot cut them 
out,

and therefore you cannot chain the simple functions.


...unless you also map return instructions within the generated
functions into branches to the soon-to-be-dropped final "return"? Not
that I know anything about qemu internals mind u... 

Seems to me one could also map them into jumps to a null function.

Although, all told, it would seem to me that what might be called for 
here is a new gcc target.  A gcc target specifically for generating qemu 
code.  That would just simply generate whatever qemu wanted for function 
postamble.


It would probably mean separating out the code intended to run as native 
code from the code intended to run on behalf of the emulated target, and 
it would mean that you'd need a "gcc-qemu" to build the latter, but it 
would solve the problem permanently.  It could also then be done in a 
cpu independent fashion such that any gcc target port might be converted 
trivially into a gcc target-for-qemu port.  This should also make the 
chaining task much simpler and since that would seem to need to be done 
at run time, this could easily be a performance enhancement as well.


I see two real downsides to this approach.  The first is that qemu 
becomes wed to gcc.  That seems to be a defacto requirement now, but 
using a custom gcc target would make that marriage pretty permanent.  
Creating qemu targets for other compilers would be near impossible, 
although if the code were properly separated, you could still use a 
non-gcc target for the intended-for-host instructions.


The second downside is that some of the qemu support stuff would no 
longer be in the qemu code distribution.  Instead, it would be in gcc.  
This opens the possiblity for version slew problems and authority over 
maintenance issues in the long term.  Administratively, it'd be an 
additional load.


--rich


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel