from:"qemu\-devel"


Hi All,


After booting KVM using the flash image as both a regular disk and a 
usb storage device.. /dev/sda is detected from ata1.00 and /dev/sdb is 
detected from usb-storage-1-1:1.0.  Both /dev/sdX devices are the same 
disk / partition layout.





---
Thanks,
Dyweni



On Thu, 19 Jan 2012 06:57:59 -0600, Dyweni - Qemu-Devel wrote:


Hi,

I am unable to boot KVM using a usb flash drive. I'm using QEMU-KVM
built
from GIT MASTER as of this morning.

Here's my QEMU-KVM startup options:

qemu-system-x86_64
-curses
-m 512
-snapshot
-device piix3-usb-uhci
-drive id=usbflash,file=flash.img,if=none,boot=on,cache=writeback
-device usb-storage,drive=usbflash
-net nic,macaddr=$(getmacpublic),vlan=0 -net
tap,vlan=0,ifname=$publictap,script=no
-net nic,macaddr=$(getmacprivate),vlan=1 -net
tap,vlan=1,ifname=$privatetap,script=no
$*

Here's the debugging output from SeaBIOS. (Notice the 'Unable to
configure USB MSC device.' message):

+ qemu-system-x86_64 -m 512 -snapshot -device piix3-usb-uhci -drive
id=usbflash,file=flash.img,if=none,boot=on,cache=writeback -device
usb-storage,drive=usbflash -net nic,macaddr=00:AA:00:AA:62:AA,vlan=0
-net tap,vlan=0,ifname=tap0,script=no -net
nic,macaddr=00:AA:00:D2:D1:BB,vlan=1 -net
tap,vlan=1,ifname=tap1,script=no -chardev stdio,id=seabios -device
isa-debugcon,iobase=0x402,chardev=seabios
qemu-kvm: boot=on|off is deprecated and will be ignored. Future
versions will reject this parameter. Please update your scripts.
Start bios (version 1.6.3)
Ram Size=0x2000 (0x high)
Relocating init from 0x000e3b20 to 0x1ffe12e0 (size 60412)
CPU Mhz=3601
=== PCI bus & bridge init ===
PCI: pci_bios_init_bus_rec bus = 0x0
=== PCI device probing ===
Found 8 PCI devices (max PCI bus is 00)
=== PCI new allocation pass #1 ===
PCI: check devices bus 0
=== PCI new allocation pass #2 ===
PCI: init bases bus 0 (primary)
type io max 100 sum 230 base c000
size 100: 2 bar(s), c000 -> c1ff
size 20: 1 bar(s), c200 -> c21f
size 10: 1 bar(s), c220 -> c22f
type mem max 1 sum 33000 base febc
size 1: 3 bar(s), febc -> febe
size 1000: 3 bar(s), febf -> febf2fff
type prefmem max 200 sum 200 base fc00
size 200: 1 bar(s), fc00 -> fdff
PCI: map device bus 0, bfd 0x0
PCI: map device bus 0, bfd 0x8
PCI: map device bus 0, bfd 0x9
bar 4, addr c220, size 10 [io]
PCI: map device bus 0, bfd 0xb
PCI: map device bus 0, bfd 0x10
bar 0, addr fc00, size 200 [mem]
bar 1, addr febf, size 1000 [mem]
bar 6, addr febc, size 1 [mem]
PCI: map device bus 0, bfd 0x18
bar 0, addr c000, size 100 [io]
bar 1, addr febf1000, size 100 [mem]
bar 6, addr febd, size 1 [mem]
PCI: map device bus 0, bfd 0x20
bar 0, addr c100, size 100 [io]
bar 1, addr febf2000, size 100 [mem]
bar 6, addr febe, size 1 [mem]
PCI: map device bus 0, bfd 0x28
bar 4, addr c200, size 20 [io]
PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237
PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000
PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010
PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113
PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8
PCI: bus=0 devfn=0x18: vendor_id=0x10ec device_id=0x8139
PCI: bus=0 devfn=0x20: vendor_id=0x10ec device_id=0x8139
PCI: bus=0 devfn=0x28: vendor_id=0x8086 device_id=0x7020
PIIX3/PIIX4 init: elcr=00 0c

Found 1 cpu(s) max supported 1 cpu(s)
MP table addr=0x000fd620 MPC table addr=0x000fd630 size=240
SMBIOS ptr=0x000fd600 table=0x000fd4f0 size=263
ACPI tables: RSDP=0x000fd4c0 RSDT=0x1fffd7b0
Scan for VGA option rom
Running option rom at c000:0003
Turning on vga text mode console
SeaBIOS (version 1.6.3)

UHCI init on dev 00:05.0 (io=c200)
Found 1 lpt ports
Found 1 serial ports
ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
ATA controller 2 at 170/374/0 (irq 15 dev 9)
DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
ebda moved from 9fc00 to 9f800
USB MSC vendor='QEMU' product='QEMU HARDDISK' rev='1.0.' type=0
removable=0
Unable to configure USB MSC device.
PS2 keyboard initialized
All threads complete.
Scan for option roms
Running option rom at c900:0003
pmm call arg1=1
pmm call arg1=0
pmm call arg1=1
pmm call arg1=0
Running option rom at ca00:0003
pmm call arg1=1
pmm call arg1=1
Searching bootorder for: /pci@i0cf8/*@3
Searching bootorder for: /pci@i0cf8/*@4
Searching bootorder for: /rom@genroms/vapic.bin
Running option rom at cb00:0003
ebda moved from 9f800 to 9f000
Returned 53248 bytes of ZoneHigh
e820 map has 7 items:
0:  - 0009f000 = 1 RAM
1: 0009f000 - 000a = 2 RESERVED
2: 000f - 0010 = 2 RESERVED
3: 0010 - 1fffd000 = 1 RAM
4: 1fffd000 - 2000 = 2 RESERVED
5: feffc000 - ff00 = 2 RESERVED
6: fffc - 0001 = 2 RESERVED
enter handle_19:

[Qemu-devel] USB Booting


Hi All,

In QEMU-KVM 0.14, I was able to simulate booting from a USB Flash drive 
with

these options:

 qemu-system-x86_64 \
-curses \
-m 512 \
-snapshot \
-device piix3-usb-uhci \
-drive id=usbflash,file=flash.img,if=none,boot=on,cache=writeback \
-device usb-storage,drive=usbflash \
 	-net nic,macaddr=$(getmacpublic),vlan=0 -net 
tap,vlan=0,ifname=$publictap,script=no \
 	-net nic,macaddr=$(getmacprivate),vlan=1 -net 
tap,vlan=1,ifname=$privatetap,script=no \

$*


In QEMU-KVM (git master, 9501d0f1b6efc83f69d06b27a625bad71d30d58b), I 
find
that the boot=on parameter for -drive is deprecated and KVM doesn't 
start.
After I remove that parameter, KVM starts but it doesn't find the USB 
Flash

drive to boot from.

Is there a new set of switches I can use to continue simulating booting 
from

a USB Flash drive?


--
Thanks,
Dyweni

[Qemu-devel] Error booting from USB Storage Device in QEMU-KVM GIT MASTER


Hi,

I am unable to boot KVM using a usb flash drive. I'm using QEMU-KVM 
built

from GIT MASTER as of this morning.


Here's my QEMU-KVM startup options:

 qemu-system-x86_64 \
-curses \
-m 512 \
-snapshot \
-device piix3-usb-uhci \
-drive id=usbflash,file=flash.img,if=none,boot=on,cache=writeback \
-device usb-storage,drive=usbflash \
 	-net nic,macaddr=$(getmacpublic),vlan=0 -net 
tap,vlan=0,ifname=$publictap,script=no \
 	-net nic,macaddr=$(getmacprivate),vlan=1 -net 
tap,vlan=1,ifname=$privatetap,script=no \

$*





Here's the debugging output from SeaBIOS.  (Notice the 'Unable to 
configure USB MSC device.' message):




+ qemu-system-x86_64 -m 512 -snapshot -device piix3-usb-uhci -drive 
id=usbflash,file=flash.img,if=none,boot=on,cache=writeback -device 
usb-storage,drive=usbflash -net nic,macaddr=00:AA:00:AA:62:AA,vlan=0 
-net tap,vlan=0,ifname=tap0,script=no -net 
nic,macaddr=00:AA:00:D2:D1:BB,vlan=1 -net 
tap,vlan=1,ifname=tap1,script=no -chardev stdio,id=seabios -device 
isa-debugcon,iobase=0x402,chardev=seabios
qemu-kvm: boot=on|off is deprecated and will be ignored. Future 
versions will reject this parameter. Please update your scripts.

Start bios (version 1.6.3)
Ram Size=0x2000 (0x high)
Relocating init from 0x000e3b20 to 0x1ffe12e0 (size 60412)
CPU Mhz=3601
=== PCI bus & bridge init ===
PCI: pci_bios_init_bus_rec bus = 0x0
=== PCI device probing ===
Found 8 PCI devices (max PCI bus is 00)
=== PCI new allocation pass #1 ===
PCI: check devices bus 0
=== PCI new allocation pass #2 ===
PCI: init bases bus 0 (primary)
  type io max 100 sum 230 base c000
size  100: 2 bar(s), c000 -> c1ff
size   20: 1 bar(s), c200 -> c21f
size   10: 1 bar(s), c220 -> c22f
  type mem max 1 sum 33000 base febc
size1: 3 bar(s), febc -> febe
size 1000: 3 bar(s), febf -> febf2fff
  type prefmem max 200 sum 200 base fc00
size  200: 1 bar(s), fc00 -> fdff
PCI: map device bus 0, bfd 0x0
PCI: map device bus 0, bfd 0x8
PCI: map device bus 0, bfd 0x9
  bar 4, addr c220, size 10 [io]
PCI: map device bus 0, bfd 0xb
PCI: map device bus 0, bfd 0x10
  bar 0, addr fc00, size 200 [mem]
  bar 1, addr febf, size 1000 [mem]
  bar 6, addr febc, size 1 [mem]
PCI: map device bus 0, bfd 0x18
  bar 0, addr c000, size 100 [io]
  bar 1, addr febf1000, size 100 [mem]
  bar 6, addr febd, size 1 [mem]
PCI: map device bus 0, bfd 0x20
  bar 0, addr c100, size 100 [io]
  bar 1, addr febf2000, size 100 [mem]
  bar 6, addr febe, size 1 [mem]
PCI: map device bus 0, bfd 0x28
  bar 4, addr c200, size 20 [io]
PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237
PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000
PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010
PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113
PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8
PCI: bus=0 devfn=0x18: vendor_id=0x10ec device_id=0x8139
PCI: bus=0 devfn=0x20: vendor_id=0x10ec device_id=0x8139
PCI: bus=0 devfn=0x28: vendor_id=0x8086 device_id=0x7020
PIIX3/PIIX4 init: elcr=00 0c

Found 1 cpu(s) max supported 1 cpu(s)
MP table addr=0x000fd620 MPC table addr=0x000fd630 size=240
SMBIOS ptr=0x000fd600 table=0x000fd4f0 size=263
ACPI tables: RSDP=0x000fd4c0 RSDT=0x1fffd7b0
Scan for VGA option rom
Running option rom at c000:0003
Turning on vga text mode console
SeaBIOS (version 1.6.3)

UHCI init on dev 00:05.0 (io=c200)
Found 1 lpt ports
Found 1 serial ports
ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
ATA controller 2 at 170/374/0 (irq 15 dev 9)
DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
ebda moved from 9fc00 to 9f800
USB MSC vendor='QEMU' product='QEMU HARDDISK' rev='1.0.' type=0 
removable=0

Unable to configure USB MSC device.
PS2 keyboard initialized
All threads complete.
Scan for option roms
Running option rom at c900:0003
pmm call arg1=1
pmm call arg1=0
pmm call arg1=1
pmm call arg1=0
Running option rom at ca00:0003
pmm call arg1=1
pmm call arg1=1
Searching bootorder for: /pci@i0cf8/*@3
Searching bootorder for: /pci@i0cf8/*@4
Searching bootorder for: /rom@genroms/vapic.bin
Running option rom at cb00:0003
ebda moved from 9f800 to 9f000
Returned 53248 bytes of ZoneHigh
e820 map has 7 items:
  0:  - 0009f000 = 1 RAM
  1: 0009f000 - 000a = 2 RESERVED
  2: 000f - 0010 = 2 RESERVED
  3: 0010 - 1fffd000 = 1 RAM
  4: 1fffd000 - 2000 = 2 RESERVED
  5: feffc000 - ff00 = 2 RESERVED
  6: fffc - 0001 = 2 RESERVED
enter handle_19:
  NULL
Booting from DVD/CD...
Device reports MEDIUM NOT PRESENT
atapi_is_ready returned -1
Boot failed: Could not read from CDROM (code 0003)
enter handle_18:

  NULL
Booting from ROM...
Booting from

Re: [Qemu-devel] USB Booting


Hi All,

Here is the log when booting SeaBIOS with debuging enabled:


+ qemu-system-x86_64 -m 512 -snapshot -device piix3-usb-uhci -drive 
id=usbflash,file=flash.img,if=none,boot=on,cache=writeback -device 
usb-storage,drive=usbflash -net nic,macaddr=00:AA:00:AA:62:AA,vlan=0 
-net tap,vlan=0,ifname=tap0,script=no -net 
nic,macaddr=00:AA:00:D2:D1:BB,vlan=1 -net 
tap,vlan=1,ifname=tap1,script=no -chardev stdio,id=seabios -device 
isa-debugcon,iobase=0x402,chardev=seabios
qemu-kvm: boot=on|off is deprecated and will be ignored. Future 
versions will reject this parameter. Please update your scripts.

Start bios (version 1.6.3)
Ram Size=0x2000 (0x high)
Relocating init from 0x000e3b20 to 0x1ffe12e0 (size 60412)
CPU Mhz=3601
=== PCI bus & bridge init ===
PCI: pci_bios_init_bus_rec bus = 0x0
=== PCI device probing ===
Found 8 PCI devices (max PCI bus is 00)
=== PCI new allocation pass #1 ===
PCI: check devices bus 0
=== PCI new allocation pass #2 ===
PCI: init bases bus 0 (primary)
  type io max 100 sum 230 base c000
size  100: 2 bar(s), c000 -> c1ff
size   20: 1 bar(s), c200 -> c21f
size   10: 1 bar(s), c220 -> c22f
  type mem max 1 sum 33000 base febc
size1: 3 bar(s), febc -> febe
size 1000: 3 bar(s), febf -> febf2fff
  type prefmem max 200 sum 200 base fc00
size  200: 1 bar(s), fc00 -> fdff
PCI: map device bus 0, bfd 0x0
PCI: map device bus 0, bfd 0x8
PCI: map device bus 0, bfd 0x9
  bar 4, addr c220, size 10 [io]
PCI: map device bus 0, bfd 0xb
PCI: map device bus 0, bfd 0x10
  bar 0, addr fc00, size 200 [mem]
  bar 1, addr febf, size 1000 [mem]
  bar 6, addr febc, size 1 [mem]
PCI: map device bus 0, bfd 0x18
  bar 0, addr c000, size 100 [io]
  bar 1, addr febf1000, size 100 [mem]
  bar 6, addr febd, size 1 [mem]
PCI: map device bus 0, bfd 0x20
  bar 0, addr c100, size 100 [io]
  bar 1, addr febf2000, size 100 [mem]
  bar 6, addr febe, size 1 [mem]
PCI: map device bus 0, bfd 0x28
  bar 4, addr c200, size 20 [io]
PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237
PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000
PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010
PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113
PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8
PCI: bus=0 devfn=0x18: vendor_id=0x10ec device_id=0x8139
PCI: bus=0 devfn=0x20: vendor_id=0x10ec device_id=0x8139
PCI: bus=0 devfn=0x28: vendor_id=0x8086 device_id=0x7020
PIIX3/PIIX4 init: elcr=00 0c

Found 1 cpu(s) max supported 1 cpu(s)
MP table addr=0x000fd620 MPC table addr=0x000fd630 size=240
SMBIOS ptr=0x000fd600 table=0x000fd4f0 size=263
ACPI tables: RSDP=0x000fd4c0 RSDT=0x1fffd7b0
Scan for VGA option rom
Running option rom at c000:0003
Turning on vga text mode console
SeaBIOS (version 1.6.3)

UHCI init on dev 00:05.0 (io=c200)
Found 1 lpt ports
Found 1 serial ports
ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
ATA controller 2 at 170/374/0 (irq 15 dev 9)
DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
ebda moved from 9fc00 to 9f800
USB MSC vendor='QEMU' product='QEMU HARDDISK' rev='1.0.' type=0 
removable=0

Unable to configure USB MSC device.
PS2 keyboard initialized
All threads complete.
Scan for option roms
Running option rom at c900:0003
pmm call arg1=1
pmm call arg1=0
pmm call arg1=1
pmm call arg1=0
Running option rom at ca00:0003
pmm call arg1=1
pmm call arg1=1
Searching bootorder for: /pci@i0cf8/*@3
Searching bootorder for: /pci@i0cf8/*@4
Searching bootorder for: /rom@genroms/vapic.bin
Running option rom at cb00:0003
ebda moved from 9f800 to 9f000
Returned 53248 bytes of ZoneHigh
e820 map has 7 items:
  0:  - 0009f000 = 1 RAM
  1: 0009f000 - 000a = 2 RESERVED
  2: 000f - 0010 = 2 RESERVED
  3: 0010 - 1fffd000 = 1 RAM
  4: 1fffd000 - 2000 = 2 RESERVED
  5: feffc000 - ff00 = 2 RESERVED
  6: fffc - 0001 = 2 RESERVED
enter handle_19:
  NULL
Booting from DVD/CD...
Device reports MEDIUM NOT PRESENT
atapi_is_ready returned -1
Boot failed: Could not read from CDROM (code 0003)
enter handle_18:

  NULL
Booting from ROM...
Booting from c900:0372
enter handle_18:
  NULL
Booting from ROM...
Booting from ca00:0372
In resume (status=0)
In 32bit resume
Attempting a hard reboot



---
Thanks,
Dyweni





On Thu, 19 Jan 2012 06:21:36 -0600, Dyweni - Qemu-Devel wrote:


Hi All,

In QEMU-KVM 0.14, I was able to simulate booting from a USB Flash 
drive

with
these options:

qemu-system-x86_64
-curses
-m 512
-snapshot
-device piix3-usb-uhci
-drive id=usbflash,file=flash.img,if=none,boot=on,cache=writeback
-device usb-storage,drive=usbflash
-net nic,macaddr=$(getmacpublic),vlan=0 -net
tap,vlan=0,ifname=$

Re: [Qemu-devel] [SeaBIOS] Error booting from USB Storage Device in QEMU-KVM GIT MASTER

2012-01-20 Thread Dyweni - Qemu-Devel


Hi All,

I have good and bad news...

I tested QEMU-KVM using branches 'master'
(9501d0f1b6efc83f69d06b27a625bad71d30d58b) and 'uq/master'
(6a48ffaaa732b2142c1b5030178f2d4a0fa499fe). Seabios used was the 
version
included in those branches (no -L switch). Both branches failed to 
detect
the USB Flash Drive (error message: 'Unable to configure USB MSC 
device.').


I checked out SeaBios branch 'master'
(b3df857fe6d3fffb108379637ea4a456ce6e09ba) and passed that to QEMU-KVM
using the -L switch. Both branches don't fail as bad. Both versions 
detect

the USB Flash Drive (message: 'USB MSC blksize=512 sectors=204800') and
then indicate they are booting from hard disk.

In order to see the console, I had to copy the following files into the
directory specified by the -L switch in order to see the screen:
- vgabios-cirrus.bin
- pxe-rtl8139.rom
- vapic.bin

I also noticed one new regression: booting runs REALLY REALLY slow. The
upgrade from 0.14 w/ USB to git master w/ IDE slowed down a little bit.
But this is magnitudes slower.  While I'm waiting, I see one of my 
cores

at 100% usage.

---
Thanks,
Dyweni

On Thu, 19 Jan 2012 20:57:11 -0500, Kevin O'Connor wrote:


On Thu, Jan 19, 2012 at 06:57:59AM -0600, Dyweni - Qemu-Devel wrote:
Hi, I am unable to boot KVM using a usb flash drive. I'm using 
QEMU-KVM

built from GIT MASTER as of this morning. Here's my QEMU-KVM startup
options: qemu-system-x86_64 -curses -m 512 -snapshot -device
piix3-usb-uhci -drive
id=usbflash,file=flash.img,if=none,boot=on,cache=writeback -device
usb-storage,drive=usbflash -net nic,macaddr=$(getmacpublic),vlan=0 
-net

tap,vlan=0,ifname=$publictap,script=no -net
nic,macaddr=$(getmacprivate),vlan=1 -net
tap,vlan=1,ifname=$privatetap,script=no $*

I tried a modifed version of the above, and it worked fine for me.
qemu-system-x86_64 -snapshot -L test -device piix3-usb-uhci -drive
id=usbflash,file=dos-drivec-new,if=none,cache=writeback -device
usb-storage,drive=usbflash -chardev stdio,id=seabios -device
isa-debugcon,iobase=0x402,chardev=seabios What version of qemu are 
you
using? There are a few known quirks in the seabios code that were 
fixed
recently, but I did not think they impacted the qemu emulation. 
-Kevin

[Qemu-devel] Help compiling QEMU with RBD support

2011-05-04 Thread Dyweni - Qemu-Devel

Hi List!

I'm running into an issue compiling QEMU with RBD support.

>From the Wiki (http://ceph.newdream.net/wiki/QEMU-RBD), I should be
able to do the following:

$ git clone git://git.qemu.org/qemu.git
$ cd qemu
$ ./configure --enable-rbd
$ make; make install


However, the configure command throws this error:

ERROR
ERROR: User requested feature rados block device
ERROR: configure was not able to find it
ERROR


I ran across this patchset from Josh Durgin which looks like it might
resolve this error, but I don't see it commited to GIT repository
above, or the qemu-kvm repository hosted on git.kernel.org:

[Qemu-devel] [PATCH v3 0/4] rbd improvements
http://lists.gnu.org/archive/html/qemu-devel/2011-04/msg01211.html



Before I attempt to apply Josh's patchset, I'd like to know if anyone
else on the list has ran across this before.

Thanks,
Dyweni

Re: [Qemu-devel] Help compiling QEMU with RBD support

2011-05-04 Thread Dyweni - Qemu-Devel

Hi Christian!

I have ceph 0.27 installed.  I downloaded it from:
http://ceph.newdream.net/download/ceph-0.27.tar.gz


I found the following rados/rbd included files at:

/usr/include/rados
/usr/include/rados/buffer.h
/usr/include/rados/crc32c.h
/usr/include/rados/librados.h
/usr/include/rados/librados.hpp
/usr/include/rados/page.h
/usr/include/rbd
/usr/include/rbd/librbd.h
/usr/include/rbd/librbd.hpp


I also found the following rados/rbd lib files at:

/usr/lib64/librados.so -> librados.so.2.0.0
/usr/lib64/librados.so.2 -> librados.so.2.0.0
/usr/lib64/librados.so.2.0.0
/usr/lib64/librbd.so -> librbd.so.1.0.0
/usr/lib64/librbd.so.1 -> librbd.so.1.0.0
/usr/lib64/librbd.so.1.0.0


The QEMU configure script is looking for a function called
'rados_initialize' within the header file 'rados/librados.h'.


I checked the rados include/lib files for that function,
but I don't see it:

# grep -rin rados_initialize /usr/include/rados/*
# strings /usr/lib64/librados.so | grep -i rados_initialize


Thanks,
Dyweni




> Hi Dyweni,
>
> are you sure that you have installed ceph (especially librados and the
> header files)?
>
> Josh's patches use the newer librbd from ceph 0.27. With this library
> the qemu driver gets a lot simpler and avoids code duplication in ceph
> and qemu. - It's the future, but I don't think it will solve your
> problem.
>
> Christian
>
> 2011/5/4 Dyweni - Qemu-Devel <8sscqsnyx...@dyweni.com>:
>> Hi List!
>>
>> I'm running into an issue compiling QEMU with RBD support.
>>
>> From the Wiki (http://ceph.newdream.net/wiki/QEMU-RBD), I should be
>> able to do the following:
>>
>> $ git clone git://git.qemu.org/qemu.git
>> $ cd qemu
>> $ ./configure --enable-rbd
>> $ make; make install
>>
>>
>> However, the configure command throws this error:
>>
>> ERROR
>> ERROR: User requested feature rados block device
>> ERROR: configure was not able to find it
>> ERROR
>>
>>
>> I ran across this patchset from Josh Durgin which looks like it might
>> resolve this error, but I don't see it commited to GIT repository
>> above, or the qemu-kvm repository hosted on git.kernel.org:
>>
>> [Qemu-devel] [PATCH v3 0/4] rbd improvements
>> http://lists.gnu.org/archive/html/qemu-devel/2011-04/msg01211.html
>>
>>
>>
>> Before I attempt to apply Josh's patchset, I'd like to know if anyone
>> else on the list has ran across this before.
>>
>> Thanks,
>> Dyweni
>>
>>
>>
>>
>>
>>
>

[Qemu-devel] Qemu + RBD = ceph::buffer::end_of_buffer

Hi List!

I am tripping across this error as soon as the qemu rbd disk is
probed by the windows 2000 installer:

VNC server running on `127.0.0.1:5900'
terminate called after throwing an instance of 'ceph::buffer::end_of_buffer'
  what():  buffer::end_of_buffer
Aborted (core dumped)



Has anyone else tripped across this?



I am running the following:
  Linux Kernel 2.6.37-gentoo-r4
  Ceph 0.27
  QEMU-KVM (commit 28262112181f27f302b5186f0df6428df6b513e7)
Pulled from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
And patched with Josh Durgin's "rbd improvements" patchset
 (http://lists.gnu.org/archive/html/qemu-devel/2011-04/msg01211.html)



The GDB Backtrace is:

#0  0x7f7733c2a495 in raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x7f7733c2b81f in abort () at abort.c:92
#2  0x7f7733175a25 in __gnu_cxx::__verbose_terminate_handler () at
/usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/vterminate.cc:93
#3  0x7f7733172c64 in __cxxabiv1::__terminate (handler=0x7f7733175817
<__gnu_cxx::__verbose_terminate_handler()>)
at
/usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:38
#4  0x7f7733172c8c in std::terminate () at
/usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:48
#5  0x7f7733172ea4 in __cxxabiv1::__cxa_throw (obj=0x18d62a0,
tinfo=0x7f7735d57ce0, dest=0x7f7735b4548a
)
at
/usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_throw.cc:83
#6  0x7f7735b45b31 in ceph::buffer::list::iterator::copy
(this=0x7f7731cb2930, len=4, dest=0x7f7731cb28dc "") at
include/buffer.h:381
#7  0x7f7735b483de in decode_raw<__le32> (t=@0x7f7731cb28dc, p=...) at
include/encoding.h:35
#8  0x7f7735b46a40 in decode (v=@0x7f7731cb290c, p=...) at
include/encoding.h:80
#9  0x7f7735b46b94 in decode (s=..., p=...) at include/encoding.h:189
#10 0x7f77356ea3b5 in
librados::RadosClient::C_aio_sparse_read_Ack::finish (this=0x7f77280618d0,
r=0) at librados.cc:463
#11 0x7f773572dff4 in Objecter::handle_osd_op_reply (this=0x181ff10,
m=0x18f1440) at osdc/Objecter.cc:801
#12 0x7f77356d347c in librados::RadosClient::_dispatch
(this=0x181cdc0, m=0x18f1440) at librados.cc:751
#13 0x7f77356d327c in librados::RadosClient::ms_dispatch
(this=0x181cdc0, m=0x18f1440) at librados.cc:717
#14 0x7f773571d93d in Messenger::ms_deliver_dispatch (this=0x181f300,
m=0x18f1440) at msg/Messenger.h:98
#15 0x7f773570b135 in SimpleMessenger::dispatch_entry (this=0x181f300)
at msg/SimpleMessenger.cc:352
#16 0x7f77356e49ba in SimpleMessenger::DispatchThread::entry
(this=0x181f790) at msg/SimpleMessenger.h:533
#17 0x7f773571c75d in Thread::_entry_func (arg=0x181f790) at
common/Thread.h:41
#18 0x7f7736372ac4 in start_thread (arg=) at
pthread_create.c:297
#19 0x7f7733cc938d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115



Thanks,
Dyweni

Re: [Qemu-devel] Qemu + RBD = ceph::buffer::end_of_buffer

Hi List!

I upgraded Ceph to the latest development version
Commit: 0edbc75a5fe8c3028faf85546f3264d28653ea3f
Pulled from: git://ceph.newdream.net/ceph.git

I recompiled the latest GIT version of QEMU-KVM (with Josh Durgin's
patches) against the latest git version of Ceph.

However, this error is still occurring:

terminate called after throwing an instance of 'ceph::buffer::end_of_buffer'
  what():  buffer::end_of_buffer
Aborted (core dumped)



Here's another backtrace from GDB:

#0  0x7f16ff829495 in raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x7f16ff82a81f in abort () at abort.c:92
#2  0x7f16fed74a25 in __gnu_cxx::__verbose_terminate_handler () at
/usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/vterminate.cc:93
#3  0x7f16fed71c64 in __cxxabiv1::__terminate (handler=0x7f16fed74817
<__gnu_cxx::__verbose_terminate_handler()>)
at
/usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:38
#4  0x7f16fed71c8c in std::terminate () at
/usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:48
#5  0x7f16fed71ea4 in __cxxabiv1::__cxa_throw (obj=0x1346470,
tinfo=0x7f1701952ce0, dest=0x7f17017403d4
)
at
/usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_throw.cc:83
#6  0x7f1701740a7b in ceph::buffer::list::iterator::copy
(this=0x7f16fd8b1930, len=4, dest=0x7f16fd8b18dc "") at
include/buffer.h:379
#7  0x7f1701743328 in decode_raw<__le32> (t=@0x7f16fd8b18dc, p=...) at
include/encoding.h:35
#8  0x7f170174198a in decode (v=@0x7f16fd8b190c, p=...) at
include/encoding.h:80
#9  0x7f1701741ade in decode (s=..., p=...) at include/encoding.h:189
#10 0x7f17012e8369 in
librados::RadosClient::C_aio_sparse_read_Ack::finish (this=0x7f16f40d6200,
r=0) at librados.cc:463
#11 0x7f170132bb5a in Objecter::handle_osd_op_reply (this=0x13423e0,
m=0x1346520) at osdc/Objecter.cc:794
#12 0x7f17012d1444 in librados::RadosClient::_dispatch
(this=0x133f810, m=0x1346520) at librados.cc:751
#13 0x7f17012d1244 in librados::RadosClient::ms_dispatch
(this=0x133f810, m=0x1346520) at librados.cc:717
#14 0x7f170131b57b in Messenger::ms_deliver_dispatch (this=0x1341910,
m=0x1346520) at msg/Messenger.h:98
#15 0x7f17013090d3 in SimpleMessenger::dispatch_entry (this=0x1341910)
at msg/SimpleMessenger.cc:352
#16 0x7f17012e296e in SimpleMessenger::DispatchThread::entry
(this=0x1341da0) at msg/SimpleMessenger.h:533
#17 0x7f170131a39b in Thread::_entry_func (arg=0x1341da0) at
common/Thread.h:41
#18 0x7f1701f6dac4 in start_thread (arg=) at
pthread_create.c:297
#19 0x7f16ff8c838d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115


Thanks,
Dyweni




> Hi List!
>
> I am tripping across this error as soon as the qemu rbd disk is
> probed by the windows 2000 installer:
>
> VNC server running on `127.0.0.1:5900'
> terminate called after throwing an instance of
> 'ceph::buffer::end_of_buffer'
>   what():  buffer::end_of_buffer
> Aborted (core dumped)
>
>
>
> Has anyone else tripped across this?
>
>
>
> I am running the following:
>   Linux Kernel 2.6.37-gentoo-r4
>   Ceph 0.27
>   QEMU-KVM (commit 28262112181f27f302b5186f0df6428df6b513e7)
> Pulled from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
> And patched with Josh Durgin's "rbd improvements" patchset
>  (http://lists.gnu.org/archive/html/qemu-devel/2011-04/msg01211.html)
>
>
>
> The GDB Backtrace is:
>
> #0  0x7f7733c2a495 in raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1  0x7f7733c2b81f in abort () at abort.c:92
> #2  0x7f7733175a25 in __gnu_cxx::__verbose_terminate_handler () at
> /usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/vterminate.cc:93
> #3  0x7f7733172c64 in __cxxabiv1::__terminate (handler=0x7f7733175817
> <__gnu_cxx::__verbose_terminate_handler()>)
> at
> /usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:38
> #4  0x7f7733172c8c in std::terminate () at
> /usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:48
> #5  0x7f7733172ea4 in __cxxabiv1::__cxa_throw (obj=0x18d62a0,
> tinfo=0x7f7735d57ce0, dest=0x7f7735b4548a
> )
> at
> /usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_throw.cc:83
> #6  0x7f7735b45b31 in ceph::buffer::list::iterator::copy
> (this=0x7f7731cb2930, len=4, dest=0x7f7731cb28dc "") at
> include/buffer.h:381
> #7  0x7f7735b483de in decode_raw<__le32> (t=@0x7f7731cb28dc, p=...) at
> include/encoding.h:35
> #8  0x7f7735b46a40 in decode (v=@0x7f7731cb290c, p=...) at
> include/encoding.h:80
> #9  0x7f7735b46b94 in deco

Re: [Qemu-devel] Qemu + RBD = ceph::buffer::end_of_buffer

Hi Josh/Lists!

463 ::decode(*data_bl, iter);
(gdb) print r
$1 = 0
(gdb) print data_bl
$2 = (ceph::bufferlist *) 0x7f16f40d6060
(gdb) print data_bl->_len
$3 = 0
(gdb) print iter->off
$4 = 20


Thanks,
Dyweni



> CCing the ceph list.
>
> On 05/06/2011 12:23 PM, Dyweni - Qemu-Devel wrote:
>> Hi List!
>>
>> I upgraded Ceph to the latest development version
>>  Commit: 0edbc75a5fe8c3028faf85546f3264d28653ea3f
>>  Pulled from: git://ceph.newdream.net/ceph.git
>>
>> I recompiled the latest GIT version of QEMU-KVM (with Josh Durgin's
>> patches) against the latest git version of Ceph.
>>
>> However, this error is still occurring:
>>
>> terminate called after throwing an instance of
>> 'ceph::buffer::end_of_buffer'
>>what():  buffer::end_of_buffer
>> Aborted (core dumped)
>>
>>
>>
>> Here's another backtrace from GDB:
>>
>> #0  0x7f16ff829495 in raise (sig=) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> #1  0x7f16ff82a81f in abort () at abort.c:92
>> #2  0x7f16fed74a25 in __gnu_cxx::__verbose_terminate_handler () at
>> /usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/vterminate.cc:93
>> #3  0x7f16fed71c64 in __cxxabiv1::__terminate
>> (handler=0x7f16fed74817
>> <__gnu_cxx::__verbose_terminate_handler()>)
>>  at
>> /usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:38
>> #4  0x7f16fed71c8c in std::terminate () at
>> /usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:48
>> #5  0x7f16fed71ea4 in __cxxabiv1::__cxa_throw (obj=0x1346470,
>> tinfo=0x7f1701952ce0, dest=0x7f17017403d4
>> )
>>  at
>> /usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_throw.cc:83
>> #6  0x7f1701740a7b in ceph::buffer::list::iterator::copy
>> (this=0x7f16fd8b1930, len=4, dest=0x7f16fd8b18dc "") at
>> include/buffer.h:379
>> #7  0x7f1701743328 in decode_raw<__le32>  (t=@0x7f16fd8b18dc, p=...)
>> at
>> include/encoding.h:35
>> #8  0x7f170174198a in decode (v=@0x7f16fd8b190c, p=...) at
>> include/encoding.h:80
>> #9  0x7f1701741ade in decode (s=..., p=...) at
>> include/encoding.h:189
>> #10 0x7f17012e8369 in
>> librados::RadosClient::C_aio_sparse_read_Ack::finish
>> (this=0x7f16f40d6200,
>> r=0) at librados.cc:463
>> #11 0x7f170132bb5a in Objecter::handle_osd_op_reply (this=0x13423e0,
>> m=0x1346520) at osdc/Objecter.cc:794
>> #12 0x7f17012d1444 in librados::RadosClient::_dispatch
>> (this=0x133f810, m=0x1346520) at librados.cc:751
>> #13 0x7f17012d1244 in librados::RadosClient::ms_dispatch
>> (this=0x133f810, m=0x1346520) at librados.cc:717
>> #14 0x7f170131b57b in Messenger::ms_deliver_dispatch
>> (this=0x1341910,
>> m=0x1346520) at msg/Messenger.h:98
>> #15 0x7f17013090d3 in SimpleMessenger::dispatch_entry
>> (this=0x1341910)
>> at msg/SimpleMessenger.cc:352
>> #16 0x7f17012e296e in SimpleMessenger::DispatchThread::entry
>> (this=0x1341da0) at msg/SimpleMessenger.h:533
>> #17 0x7f170131a39b in Thread::_entry_func (arg=0x1341da0) at
>> common/Thread.h:41
>> #18 0x7f1701f6dac4 in start_thread (arg=) at
>> pthread_create.c:297
>> #19 0x7f16ff8c838d in clone () at
>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
>
> I haven't seen that error before, but it's probably a bug in the OSD
> where it doesn't set an error code. If you've still got the core file,
> could you go to frame 10 and send us the values of r, bl._len, and
> iter.off?
>
> Thanks,
> Josh
>

Re: [Qemu-devel] Qemu + RBD = ceph::buffer::end_of_buffer

Hi Sage/Lists!


(gdb) print c->bl._len
$1 = 20


And in case this is helpful:

(gdb) print *c
$2 = {lock = {name = 0x7f1701430f8d "AioCompletionImpl lock", id = -1,
recursive = false, lockdep = true, backtrace = false, _m = {__data =
{__lock = 1, __count = 0,
__owner = 25800, __nusers = 1, __kind = 2, __spins = 0, __list =
{__prev = 0x0, __next = 0x0}},
  __size =
"\001\000\000\000\000\000\000\000\310d\000\000\001\000\000\000\002",
'\000' , __align = 1}, nlock = 1}, cond = {
_vptr.Cond = 0x7f1701952bd0, _c = {__data = {__lock = 0, __futex = 0,
__total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0,
__nwaiters = 0,
__broadcast_seq = 0}, __size = '\000' , __align
= 0}}, ref = 1, rval = 0, released = true, ack = true, safe =
false, objver = {version = 0,
epoch = 0, __pad = 0}, callback_complete = 0x7f170173de33
,
  callback_safe = 0x7f170173d8bd , callback_arg = 0x7f16f40d6010, bl = {
_buffers = { >> = {
_M_impl = { >> =
{<__gnu_cxx::new_allocator >> =
{}, }, _M_node = {_M_next =
0x1350530, _M_prev = 0x1350530}}}, }, _len = 20,
append_buffer = {_raw = 0x0, _off = 0, _len = 0}, last_p = {
  bl = 0x7f16f40d6170, ls = 0x7f16f40d6170, off = 0, p = {_M_node =
0x7f16f40d6170}, p_off = 0}}, pbl = 0x0, buf = 0x0, maxlen = 0}



Thanks,
Dyweni




> On Fri, 6 May 2011, Dyweni - Qemu-Devel wrote:
>> Hi Josh/Lists!
>>
>> 463 ::decode(*data_bl, iter);
>> (gdb) print r
>> $1 = 0
>> (gdb) print data_bl
>> $2 = (ceph::bufferlist *) 0x7f16f40d6060
>> (gdb) print data_bl->_len
>> $3 = 0
>
> What about c->bl._len?
>
> sage
>
>
>> (gdb) print iter->off
>> $4 = 20
>>
>>
>> Thanks,
>> Dyweni
>>
>>
>>
>> > CCing the ceph list.
>> >
>> > On 05/06/2011 12:23 PM, Dyweni - Qemu-Devel wrote:
>> >> Hi List!
>> >>
>> >> I upgraded Ceph to the latest development version
>> >>   Commit: 0edbc75a5fe8c3028faf85546f3264d28653ea3f
>> >>   Pulled from: git://ceph.newdream.net/ceph.git
>> >>
>> >> I recompiled the latest GIT version of QEMU-KVM (with Josh Durgin's
>> >> patches) against the latest git version of Ceph.
>> >>
>> >> However, this error is still occurring:
>> >>
>> >> terminate called after throwing an instance of
>> >> 'ceph::buffer::end_of_buffer'
>> >>what():  buffer::end_of_buffer
>> >> Aborted (core dumped)
>> >>
>> >>
>> >>
>> >> Here's another backtrace from GDB:
>> >>
>> >> #0  0x7f16ff829495 in raise (sig=) at
>> >> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> >> #1  0x7f16ff82a81f in abort () at abort.c:92
>> >> #2  0x7f16fed74a25 in __gnu_cxx::__verbose_terminate_handler ()
>> at
>> >> /usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/vterminate.cc:93
>> >> #3  0x7f16fed71c64 in __cxxabiv1::__terminate
>> >> (handler=0x7f16fed74817
>> >> <__gnu_cxx::__verbose_terminate_handler()>)
>> >>  at
>> >> /usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:38
>> >> #4  0x7f16fed71c8c in std::terminate () at
>> >> /usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:48
>> >> #5  0x7f16fed71ea4 in __cxxabiv1::__cxa_throw (obj=0x1346470,
>> >> tinfo=0x7f1701952ce0, dest=0x7f17017403d4
>> >> )
>> >>  at
>> >> /usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_throw.cc:83
>> >> #6  0x7f1701740a7b in ceph::buffer::list::iterator::copy
>> >> (this=0x7f16fd8b1930, len=4, dest=0x7f16fd8b18dc "") at
>> >> include/buffer.h:379
>> >> #7  0x7f1701743328 in decode_raw<__le32>  (t=@0x7f16fd8b18dc,
>> p=...)
>> >> at
>> >> include/encoding.h:35
>> >> #8  0x7f170174198a in decode (v=@0x7f16fd8b190c, p=...) at
>> >> include/encoding.h:80
>> >> #9  0x7f1701741ade in decode (s=..., p=...) at
>> >> include/encoding.h:189
>> >> #10 0x7f17012e8369 in
>> >> librados::RadosClient::C_aio_sparse_read_Ack::finish
>> >> (this=0x7f16f40d6200,
>> >> r=0) at librados.cc:463
>> >> #11 0x7f170132bb5a in Objecter::handle_osd_op_reply
>> (this=0x13423e0,
>> >> m=0x1346520) at osdc/Objecter.cc:794
>> >> #12 0x7f1701

Re: [Qemu-devel] Qemu + RBD = ceph::buffer::end_of_buffer

Hi Sage/Lists!


(gdb) f 8
#8  0x7f170174198a in decode (v=@0x7f16fd8b190c, p=...) at
include/encoding.h:80
80  WRITE_INTTYPE_ENCODER(uint32_t, le32)
(gdb) p n
No symbol "n" in current context.
(gdb) p s
No symbol "s" in current context.


(gdb) f 9
#9  0x7f1701741ade in decode (s=..., p=...) at include/encoding.h:189
189   decode(len, p);
(gdb) p n
No symbol "n" in current context.
(gdb) p s
$3 = (ceph::bufferlist &) @0x7f16f40d6060: {_buffers =
{ >>
= {
  _M_impl = { >> =
{<__gnu_cxx::new_allocator >> =
{}, }, _M_node = {_M_next =
0x7f16f40d6060, _M_prev = 0x7f16f40d6060}}}, }, _len
= 0, append_buffer = {_raw = 0x0, _off = 0, _len = 0}, last_p = {
bl = 0x7f16f40d6060, ls = 0x7f16f40d6060, off = 0, p = {_M_node =
0x7f16f40d6060}, p_off = 0}}


Sorry, I don't have access to IRC from where I am at.

Thanks,
Dyweni




> f 9  (or 8?)
> p n
> p s
>
> (BTW this might be faster over irc, #ceph on irc.oftc.net)
>
> Thanks!
> sage
>
>
> On Fri, 6 May 2011, Dyweni - Qemu-Devel wrote:
>
>> Hi Sage/Lists!
>>
>>
>> (gdb) print c->bl._len
>> $1 = 20
>>
>>
>> And in case this is helpful:
>>
>> (gdb) print *c
>> $2 = {lock = {name = 0x7f1701430f8d "AioCompletionImpl lock", id = -1,
>> recursive = false, lockdep = true, backtrace = false, _m = {__data =
>> {__lock = 1, __count = 0,
>> __owner = 25800, __nusers = 1, __kind = 2, __spins = 0, __list =
>> {__prev = 0x0, __next = 0x0}},
>>   __size =
>> "\001\000\000\000\000\000\000\000\310d\000\000\001\000\000\000\002",
>> '\000' , __align = 1}, nlock = 1}, cond = {
>> _vptr.Cond = 0x7f1701952bd0, _c = {__data = {__lock = 0, __futex =
>> 0,
>> __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0,
>> __nwaiters = 0,
>> __broadcast_seq = 0}, __size = '\000' ,
>> __align
>> = 0}}, ref = 1, rval = 0, released = true, ack = true, safe =
>> false, objver = {version = 0,
>> epoch = 0, __pad = 0}, callback_complete = 0x7f170173de33
>> ,
>>   callback_safe = 0x7f170173d8bd > void*)>, callback_arg = 0x7f16f40d6010, bl = {
>> _buffers = {> std::allocator >> = {
>> _M_impl = { >>
>> =
>> {<__gnu_cxx::new_allocator >> =
>> {}, }, _M_node = {_M_next =
>> 0x1350530, _M_prev = 0x1350530}}}, }, _len = 20,
>> append_buffer = {_raw = 0x0, _off = 0, _len = 0}, last_p = {
>>   bl = 0x7f16f40d6170, ls = 0x7f16f40d6170, off = 0, p = {_M_node =
>> 0x7f16f40d6170}, p_off = 0}}, pbl = 0x0, buf = 0x0, maxlen = 0}
>>
>>
>>
>> Thanks,
>> Dyweni
>>
>>
>>
>>
>> > On Fri, 6 May 2011, Dyweni - Qemu-Devel wrote:
>> >> Hi Josh/Lists!
>> >>
>> >> 463 ::decode(*data_bl, iter);
>> >> (gdb) print r
>> >> $1 = 0
>> >> (gdb) print data_bl
>> >> $2 = (ceph::bufferlist *) 0x7f16f40d6060
>> >> (gdb) print data_bl->_len
>> >> $3 = 0
>> >
>> > What about c->bl._len?
>> >
>> > sage
>> >
>> >
>> >> (gdb) print iter->off
>> >> $4 = 20
>> >>
>> >>
>> >> Thanks,
>> >> Dyweni
>> >>
>> >>
>> >>
>> >> > CCing the ceph list.
>> >> >
>> >> > On 05/06/2011 12:23 PM, Dyweni - Qemu-Devel wrote:
>> >> >> Hi List!
>> >> >>
>> >> >> I upgraded Ceph to the latest development version
>> >> >>Commit: 0edbc75a5fe8c3028faf85546f3264d28653ea3f
>> >> >>Pulled from: git://ceph.newdream.net/ceph.git
>> >> >>
>> >> >> I recompiled the latest GIT version of QEMU-KVM (with Josh
>> Durgin's
>> >> >> patches) against the latest git version of Ceph.
>> >> >>
>> >> >> However, this error is still occurring:
>> >> >>
>> >> >> terminate called after throwing an instance of
>> >> >> 'ceph::buffer::end_of_buffer'
>> >> >>what():  buffer::end_of_buffer
>> >> >> Aborted (core dumped)
>> >> >>
>> >> >>
>> >> >>
>> >> >> Here's another backtrace from GDB:
>> >> >>
>> >> >> #0  0x7f16ff829495 in raise (sig=) at
>> >> >> ../nptl/sysdeps/unix/sysv/linux/raise.c:6

Re: [Qemu-devel] Qemu + RBD = ceph::buffer::end_of_buffer

Hi Sage/Lists!


Yes!  The entire Ceph cluster (1 Mon, 1 MSD, 3 OSD) are 32bit linux.

The machine running Qemu is 64bit linux.


Thanks,
Dyweni



> On Fri, 6 May 2011, Dyweni - Qemu-Devel wrote:
>> Hi Sage/Lists!
>>
>>
>> (gdb) f 8
>> #8  0x7f170174198a in decode (v=@0x7f16fd8b190c, p=...) at
>> include/encoding.h:80
>> 80  WRITE_INTTYPE_ENCODER(uint32_t, le32)
>> (gdb) p n
>> No symbol "n" in current context.
>> (gdb) p s
>> No symbol "s" in current context.
>>
>>
>> (gdb) f 9
>> #9  0x7f1701741ade in decode (s=..., p=...) at
>> include/encoding.h:189
>> 189   decode(len, p);
>> (gdb) p n
>> No symbol "n" in current context.
>> (gdb) p s
>> $3 = (ceph::bufferlist &) @0x7f16f40d6060: {_buffers =
>> {
>> >>
>> = {
>>   _M_impl = { >> =
>> {<__gnu_cxx::new_allocator >> =
>> {}, }, _M_node = {_M_next =
>> 0x7f16f40d6060, _M_prev = 0x7f16f40d6060}}}, }, _len
>> = 0, append_buffer = {_raw = 0x0, _off = 0, _len = 0}, last_p = {
>> bl = 0x7f16f40d6060, ls = 0x7f16f40d6060, off = 0, p = {_M_node =
>> 0x7f16f40d6060}, p_off = 0}}
>>
>>
>> Sorry, I don't have access to IRC from where I am at.
>
> No worries.
>
> Are you OSDs, by chance, running on 32bit machines?  This looks like a
> word size encoding thing.
>
> sage
>
>
>>
>> Thanks,
>> Dyweni
>>
>>
>>
>>
>> > f 9  (or 8?)
>> > p n
>> > p s
>> >
>> > (BTW this might be faster over irc, #ceph on irc.oftc.net)
>> >
>> > Thanks!
>> > sage
>> >
>> >
>> > On Fri, 6 May 2011, Dyweni - Qemu-Devel wrote:
>> >
>> >> Hi Sage/Lists!
>> >>
>> >>
>> >> (gdb) print c->bl._len
>> >> $1 = 20
>> >>
>> >>
>> >> And in case this is helpful:
>> >>
>> >> (gdb) print *c
>> >> $2 = {lock = {name = 0x7f1701430f8d "AioCompletionImpl lock", id =
>> -1,
>> >> recursive = false, lockdep = true, backtrace = false, _m = {__data =
>> >> {__lock = 1, __count = 0,
>> >> __owner = 25800, __nusers = 1, __kind = 2, __spins = 0,
>> __list =
>> >> {__prev = 0x0, __next = 0x0}},
>> >>   __size =
>> >> "\001\000\000\000\000\000\000\000\310d\000\000\001\000\000\000\002",
>> >> '\000' , __align = 1}, nlock = 1}, cond = {
>> >> _vptr.Cond = 0x7f1701952bd0, _c = {__data = {__lock = 0, __futex
>> =
>> >> 0,
>> >> __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0,
>> >> __nwaiters = 0,
>> >> __broadcast_seq = 0}, __size = '\000' ,
>> >> __align
>> >> = 0}}, ref = 1, rval = 0, released = true, ack = true, safe =
>> >> false, objver = {version = 0,
>> >> epoch = 0, __pad = 0}, callback_complete = 0x7f170173de33
>> >> ,
>> >>   callback_safe = 0x7f170173d8bd
>> > >> void*)>, callback_arg = 0x7f16f40d6010, bl = {
>> >> _buffers = {> >> std::allocator >> = {
>> >> _M_impl = {
>> >>
>> >> =
>> >> {<__gnu_cxx::new_allocator >> =
>> >> {}, }, _M_node = {_M_next =
>> >> 0x1350530, _M_prev = 0x1350530}}}, }, _len = 20,
>> >> append_buffer = {_raw = 0x0, _off = 0, _len = 0}, last_p = {
>> >>   bl = 0x7f16f40d6170, ls = 0x7f16f40d6170, off = 0, p = {_M_node
>> =
>> >> 0x7f16f40d6170}, p_off = 0}}, pbl = 0x0, buf = 0x0, maxlen = 0}
>> >>
>> >>
>> >>
>> >> Thanks,
>> >> Dyweni
>> >>
>> >>
>> >>
>> >>
>> >> > On Fri, 6 May 2011, Dyweni - Qemu-Devel wrote:
>> >> >> Hi Josh/Lists!
>> >> >>
>> >> >> 463 ::decode(*data_bl, iter);
>> >> >> (gdb) print r
>> >> >> $1 = 0
>> >> >> (gdb) print data_bl
>> >> >> $2 = (ceph::bufferlist *) 0x7f16f40d6060
>> >> >> (gdb) print data_bl->_len
>> >> >> $3 = 0
>> >> >
>> >> > What about c->bl._len?
>> >> >
>> >> > sage
>> >> >
>> >> >
>> >> >> (gdb) print iter->off
>> >> >>

[Qemu-devel] [PATCH] e1000: Delay flush queue when receive RCTL

2019-03-13 Thread yuchenlin--- via Qemu-devel

From: yuchenlin 

Due to too early RCT0 interrput, win10x32 may hang on booting.
This problem can be reproduced by doing power cycle on win10x32 guest.
In our environment, we have 10 win10x32 and stress power cycle.
The problem will happen about 20 rounds.

Below shows some log with comment:

The normal case:

22831@1551928392.984687:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
22831@1551928392.985655:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
22831@1551928392.985801:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
22831@1551928393.056710:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
22831@1551928393.077548:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: set_ics 2, ICR 0, IMR 0
e1000: set_ics 2, ICR 2, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
22831@1551928393.102974:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
22831@1551928393.103267:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can handle
RX now
e1000: set_ics 0, ICR 2, IMR 9d <- unmask interrupt
e1000: RCTL: 255, mac_reg[RCTL] = 0x48002
e1000: set_ics 80, ICR 2, IMR 9d <- interrupt and work!
...

The bad case:

27744@1551930483.117766:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
27744@1551930483.118398:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
27744@1551930483.198063:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
27744@1551930483.218675:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: set_ics 2, ICR 0, IMR 0
e1000: set_ics 2, ICR 2, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
27744@1551930483.241768:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
27744@1551930483.241979:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can handle
RX now
e1000: set_ics 80, ICR 2, IMR 0 <- flush queue (caused by setting RCTL)
e1000: set_ics 0, ICR 82, IMR 9d <- unmask interrupt and because 0x82&0x9d
!= 0 generate interrupt, hang on here...

To workaround this problem, simply delay flush queue. Also stop receiving
when timer is going to run.

Tested on CentOS, Win7SP1x64 and Win10x32.

Signed-off-by: yuchenlin 
---
 hw/net/e1000.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 5e144cb4e4..9b39bccfb2 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -120,6 +120,8 @@ typedef struct E1000State_st {
 bool mit_irq_level;/* Tracks interrupt pin level. */
 uint32_t mit_ide;  /* Tracks E1000_TXD_CMD_IDE bit. */
 
+QEMUTimer *flush_queue_timer;
+
 /* Compatibility flags for migration to/from qemu 1.3.0 and older */
 #define E1000_FLAG_AUTONEG_BIT 0
 #define E1000_FLAG_MIT_BIT 1
@@ -366,6 +368,7 @@ static void e1000_reset(void *opaque)
 
 timer_del(d->autoneg_timer);
 timer_del(d->mit_timer);
+timer_del(d->flush_queue_timer);
 d->mit_timer_on = 0;
 d->mit_irq_level = 0;
 d->mit_ide = 0;
@@ -391,6 +394,14 @@ set_ctrl(E1000State *s, int index, uint32_t val)
 s->mac_reg[CTRL] = val & ~E1000_CTRL_RST;
 }
 
+static void
+e1000_flush_queue_timer(void *opaque)
+{
+E1000State *s = opaque;
+
+qemu_flush_queued_packets(qemu_get_queue(s->nic));
+}
+
 static void
 set_rx_control(E1000State *s, int index, uint32_t val)
 {
@@ -399,7 +410,8 @@ set_rx_control(E1000State *s, int index, uint32_t val)
 s->rxbuf_min_shift = ((val / E1000_RCTL_RDMTS_QUAT) & 3) + 1;
 DBGOUT(RX, "RCTL: %d, mac_reg[RCTL] = 0x%x\n", s->mac_reg[RDT],
s->mac_reg[RCTL]);
-qemu_flush_queued_packets(qemu_get_queue(s->nic));
+timer_mod(s->flush_queue_timer,
+  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 1000);
 }
 
 static void
@@ -837,7 +849,7 @@ e1000_can_receive(NetClientState *nc)
 E1000State *s = qemu_get_nic_opaque(nc);
 
 return e1000x_rx_ready(&s->parent_obj, s->mac_reg) &&
-e1000_has_rxbufs(s, 1);
+e1000_has_rx

Re: [Qemu-devel] [PATCH RFC v19 11/13] target-avr: Put all translation code into one compilation unit

2017-06-13 Thread Anichang via Qemu-devel

 Original Message 
Subject: Re: [Qemu-devel] [PATCH RFC v19 11/13] target-avr: Put all translation 
code into one compilation unit
Local Time: June 13, 2017 10:07 PM
UTC Time: June 13, 2017 8:07 PM
From: th...@redhat.com
To: Michael Rolnik , qemu-devel@nongnu.org
Richard Henderson , anich...@protonmail.ch

On 08.06.2017 21:38, Michael Rolnik wrote:
> From: Michael Rolnik
>
> From: Richard Henderson

From whom is this patch? ... looks like there is something wrong with
the way you send the patches...

It may have been my fault. A bit of history:
- Last year Michael Rolnik produced a target-avr patchset.
- A few days later Richard Henderson cleaned up and re-styled.
- Last week I have found Richard's repo, edited to cope with the new 
target/arch directory structure, merged into my local copy of HEAD, and built. 
Then signaled to the list, and asked Michael to fix the bugs. So he opened a 
new repo on github, I have sent a pull request and he merged my repo.

In the while Peter Maydel last week wrote (about my patches):

"Your patch attached to this mail appears to be a merge commit
of some kind. You don't want that -- you need to rebase the
AVR patches on current master, rather than merging anything."

This mistake may have been propagated. But I didn't handle this bit to Michael, 
and he might have lost these mails.

Regards

[Qemu-devel] [Bug 1169049] Re: do not stop on first gdb breakpoint with -enable-kvm

2017-06-23 Thread skovalev via Qemu-devel

Hello.

I have forgot about this. I even unable to remember what I have done.
Unfortunately I can't help you. Sorry.

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

Title:
  do not stop on first gdb breakpoint with -enable-kvm

Status in QEMU:
  Incomplete

Bug description:
  I run qemu like this:
qemu-system-x86-64 -enable-kvm -hda  -s -S,

  and start gdb with commands like this:
gdb>tartget remote localhost:1234
gdb>break *0x7c00
gdb>c

  but gdb don't stop on it. I then could break execution manually and
  then breakpoints work.

  QEMU version: 1.4.0 (from Debian repos)
  GDB version: 7.5.1 (copiled from sources, but previous was 7.4.1 from Debian 
repo)

  PS Same problem occure on Ubuntu 13.04 with same Qemu and Gdb 7.5.0
  from repo.

  Thank you

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

Re: [Qemu-devel] [PATCH RFC v19 00/13] QEMU AVR 8 bit cores

2017-06-27 Thread Anichang via Qemu-devel

Anyone can explain what is the blocking problem for this target to be pulled 
upstream?
I apologize for bothering but I don't have the workflow clear in my mind.
thanks,
Anichang

>  Original Message 
> Subject: Re: [PATCH RFC v19 00/13] QEMU AVR 8 bit cores
> Local Time: June 22, 2017 9:15 AM
> UTC Time: June 22, 2017 7:15 AM
> From: mrol...@gmail.com
> To: QEMU Developers 
> Anichang , Michael Rolnik 
>
> Hi all,
> are there any action items for me?
> Regards,
> Michael
>
> On Thu, Jun 8, 2017 at 9:49 PM, Michael Rolnik  wrote:
>
>> This series of patches adds 8bit AVR cores to QEMU.
>> All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully 
>> tested yet.
>> However I was able to execute simple code with functions. e.g fibonacci 
>> calculation.
>> This series of patches include a non real, sample board.
>> No fuses support yet. PC is set to 0 at reset.
>> the patches include the following
>> 1. just a basic 8bit AVR CPU, without instruction decoding or translation
>> 2. CPU features which allow define the following 8bit AVR cores
>> avr1
>> avr2 avr25
>> avr3 avr31 avr35
>> avr4
>> avr5 avr51
>> avr6
>> xmega2 xmega4 xmega5 xmega6 xmega7
>> 3. a definition of sample machine with SRAM, FLASH and CPU which allows to 
>> execute simple code
>> 4. encoding for all AVR instructions
>> 5. interrupt handling
>> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
>> 7. a decoder which given an opcode decides what istruction it is
>> 8. translation of AVR instruction into TCG
>> 9. all features together
>> changes since v3
>> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of 0x00ff) 
>> for faster address manipulaton
>> 2. ffs changed to ctz32
>> 3. duplicate code removed at avr_cpu_do_interrupt
>> 4. using andc instead of not + and
>> 5. fixing V flag calculation in varios instructions
>> 6. freeing local variables in PUSH
>> 7. tcg_const_local_i32 -> tcg_const_i32
>> 8. using sextract32 instead of my implementation
>> 9. fixing BLD instruction
>> 10.xor(r) instead of 0xff - r at COM
>> 11.fixing MULS/MULSU not to modify inputs' content
>> 12.using SUB for NEG
>> 13.fixing tcg_gen_qemu_ld/st call in XCH
>> changes since v4
>> 1. target is now defined as big endian in order to optimize push_ret/pop_ret
>> 2. all style warnings are fixed
>> 3. adding cpu_set/get_sreg functions
>> 4. simplifying gen_goto_tb as there is no real paging
>> 5. env->pc -> env->pc_w
>> 6. making flag dump more compact
>> 7. more spacing
>> 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
>> 9. removing avr_set_feature
>> 10. SPL/SPH set bug fix
>> 11. switching stb_phys to cpu_stb_data
>> 12. cleaning up avr_decode
>> 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
>> 14. saving CPU features (savevm)
>> changes since v5
>> 1. BLD bug fix
>> 2. decoder generator is added
>> chages since v6
>> 1. using cpu_get_sreg/cpu_set_sreg in 
>> avr_cpu_gdb_read_register/avr_cpu_gdb_write_register
>> 2. configure the target as little endian because otherwise GDB does not work
>> 3. fixing and testing gen_push_ret/gen_pop_ret
>> changes since v7
>> 1. folding back v6
>> 2. logging at helper_outb and helper_inb are done for non supported yet 
>> registers only
>> 3. MAINTAINERS updated
>> changes since v8
>> 1. removing hw/avr from hw/Makefile.obj as it should not be built for all
>> 2. making linux compilable
>> 3. testing on
>> a. Mac, Apple LLVM version 7.0.0
>> b. Ubuntu 12.04, gcc 4.9.2
>> c. Fedora 23, gcc 5.3.1
>> 4. folding back some patches
>> 5. translation bug fixes for ORI, CPI, XOR instructions
>> 6. propper handling of cpu register writes though memory
>> changes since v9
>> 1. removing forward declarations of static functions
>> 2. disabling debug prints
>> 3. switching to case range instead of if else if ...
>> 4. LD/ST IN/OUT accessing CPU maintainder registers are not routed to any 
>> device
>> 5. commenst about sample board and sample IO device added
>> 6. sample board description is more descriptive now
>> 7. memory_region_allocate_system_memory is used to create RAM
>> 8. now there are helper_fullrd & helper_fullwr when LD/ST try to access 
>> registers
>> changes since v10
>> 1. movig back fullwr & fullrd into the commit where outb and inb were 
>> introduced
>> 2. changing tlb_fill function signature
>> 3. adding empty line between functions
>> 4. adding newline on the last line of the file
>> 5. using tb->flags to generae full access ST/LD instructions
>> 6. fixing SBRC bug
>> 7. folding back 10th commit
>> 8. whenever a new file is introduced it's added to Makefile.objs
>> changes since v11
>> 1. updating to v2.7.0-rc
>> 2. removing assignment to env->fullacc from gen_intermediate_code
>> changes since v12
>> 1. fixing spacing
>> 2. fixing get/put_segment functions
>> 3. removing target-avr/machine.h file
>> 4. VMSTATE_SINGLE_TEST -> VMSTATE_SINGLE
>> 5. comment spelling
>> 6. removing hw/avr/sample_io.c
>> 7. char const* -> const char*
>> 8. proper ram allo

[Qemu-devel] Target AVR

2017-06-01 Thread Anichang via Qemu-devel

Hi all,

I just resurrected the target-avr patchset from Michael Rolnik. Following the 
details:

commit f2bca179dbfc3f378b131ed619d07db946bae598
Merge: 43771d5 ed250c0
Author: Ani Chang 
Date: Fri Jun 2 01:17:34 2017 +0200

target/avr: resurrected (see mailing list qemu-devel, Richard Henderson on Sep 
20, 2016 at 8:35pm)
and fixed (it builds).

Details:
- merge remote git://github.com/rth7680/qemu.git tags/pull-avr-20160920 into 
master
- fixed include/sysemu/arch_init.h (i.e.: bump QEMU_ARCH_AVR from 1<<17 to 
1<<18)
- fixed target/avr/cpu.c (i.e.: remove one function arg)
- fixed target/avr/machine.c (i.e.: fix a bunch of getters/setters signatures)

Running the sample board outputs:

$ ./qemu-system-avr
Unexpected error in object_property_add() at qom/object.c:940:
qemu-system-avr: attempt to add duplicate property 'memory' to object (type 
'avr5-avr')
Aborted (core dumped)
$

Signed-off-by: Ani Chang 

commit 43771d5d92312504305c19abe29ec5bfabd55f01
Merge: c077a99 c064477
Author: Peter Maydell 
Date: Thu Jun 1 16:39:16 2017 +0100

Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2017-05-31' into 
staging
...
---

Following the output of 'make check'.

...
GTESTER check-qtest-avr
Unexpected error in object_property_add() at qom/object.c:940:
attempt to add duplicate property 'memory' to object (type 'xmega7-avr')
Broken pipe
GTester: last random seed: R02Sb7127f88337efa767b5e96a88046ebc1
Unexpected error in object_property_add() at qom/object.c:940:
qemu-system-avr: attempt to add duplicate property 'memory' to object (type 
'avr5-avr')
Broken pipe
GTester: last random seed: R02S94aa640298a8d5a71d11208b95363edd
Unexpected error in object_property_add() at qom/object.c:940:
qemu-system-avr: attempt to add duplicate property 'memory' to object (type 
'avr5-avr')
Broken pipe
GTester: last random seed: R02S76c62d67e22fbb237a3431358e65d6c2
/qemu-test/tests/Makefile.include:824: recipe for target 'check-qtest-avr' 
failed
make: *** [check-qtest-avr] Error 1
$
---

I have no idea what to do from here. How to solve the "attempt to add duplicate 
property 'memory' to object" error?

Regards

[Qemu-devel] [PATCH] [pckbd] Prevent IRQs when the guest disables the mouse

2017-10-12 Thread geoff--- via Qemu-devel

When the guest OS needs to send the mouse commands it will at least in 
the case
of Windows 10 set the KBD_MODE_DISABLE_MOUSE bit to prevent interrupts 
from

causing stream desynchronisation.

Here is Windows 10 attempting to issue a PS/2 mouse reset without this 
fix where
you can see the mouse positional data was returned as the answer to the 
get type

command.

KBD: kbd: write cmd=0xd4  // write next cmd to the aux port
KBD: kbd: read status=0x1c
KBD: kbd: read status=0x1c
KBD: kbd: read status=0x1c
KBD: kbd: write data=0xff
kbd: write mouse 0xff // reset
KBD: kbd: read status=0x3d
KBD: kbd: read status=0x3d
KBD: kbd: read data=0xfa  // ack
KBD: kbd: read status=0x3d
KBD: kbd: read status=0x3d
KBD: kbd: read data=0xaa  // self-test good
KBD: kbd: read status=0x3d
KBD: kbd: read status=0x3d
KBD: kbd: read data=0x00  // the device type
KBD: kbd: read status=0x3d
KBD: kbd: write cmd=0xd4  // write cmd to the aux port
KBD: kbd: read status=0x3d
KBD: kbd: write data=0xf2
kbd: write mouse 0xf2 // get type
KBD: kbd: read status=0x3d
KBD: kbd: read status=0x3d
KBD: kbd: read data=0x08  // mouse data byte 1
KBD: kbd: read status=0x3d
KBD: kbd: read status=0x3d
KBD: kbd: read data=0x00  // mouse data byte 2
KBD: kbd: read status=0x3d
KBD: kbd: read status=0x3d
KBD: kbd: read data=0x00  // mouse data byte 3
KBD: kbd: read status=0x3d
KBD: kbd: read status=0x3d
KBD: kbd: read data=0xfa  // the ack for the get type above
KBD: kbd: read status=0x3d
KBD: kbd: read status=0x3d
KBD: kbd: read data=0x00  // the device type
KBD: kbd: read status=0x3d
KBD: kbd: read status=0x3d
KBD: kbd: read data=0x08  // mouse data byte 1
KBD: kbd: read status=0x3d
KBD: kbd: read status=0x3d
KBD: kbd: read data=0x00  // mouse data byte 2

Signed-off-by: Geoffrey McRae 
---
 hw/input/pckbd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index c479f827b6..78d5356817 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -168,7 +168,8 @@ static void kbd_update_irq(KBDState *s)
 if (s->pending == KBD_PENDING_AUX) {
 s->status |= KBD_STAT_MOUSE_OBF;
 s->outport |= KBD_OUT_MOUSE_OBF;
-if (s->mode & KBD_MODE_MOUSE_INT)
+if ((s->mode & KBD_MODE_MOUSE_INT) &&
+!(s->mode & KBD_MODE_DISABLE_MOUSE))
 irq_mouse_level = 1;
 } else {
 if ((s->mode & KBD_MODE_KBD_INT) &&
--
2.11.0

[Qemu-devel] ivshmem Windows Driver

2017-10-15 Thread geoff--- via Qemu-devel


Hi All,

I am writing some code that needs to share a block of ram between a 
Windows guest and Linux host. For this I am using the ivshmem device and 
I have written a very primitive driver for windows that allows a single 
application to request to memory map the pci bar (shared memory) into 
the program's context using DeviceIoControl.


This is all working fine, but the next problem is I need the driver to 
be signed. In it's current state I would not even suggest it be signed 
as it was just hacked together to test my concept, but now I know it's 
viable I would be willing to invest whatever time is required to write a 
driver that would be acceptable for signing.


The ideal driver would be general purpose and could be leveraged for any 
user mode application use, not just my specific case. It would need to 
implement the IRQ/even features of ivshmem and possibly even some kind 
of security to prevent unauthorized use by rogue applications (shared 
secret configured on the chardev?).


I have several qustions:

  1) Has someone done this? I can't find any reference to a windows 
driver for this device anywhere.
  2) If I was to pursue writing this driver, how would be the best way 
to go about it so as to ensure that it is in a state that it could be 
signed with the RedHat vendor key?

  3) What is the likelihood of having such a driver signed?
  4) Is there a preferred git host for such a driver?

Kind Regards
-Geoff

[Qemu-devel] .qcow file recovery

2017-12-06 Thread RR via Qemu-devel


Hi,

A .qcow file was deleted by mistake. No recovery or backup is available. 
Hard disk was plugged out from the NAS after half a hour to prevent 
Synology OS operations writing over desallocated stockage. The file 
system on the virtual disk was ntfs. Virtualisation OS is Proxmox.


Ease Us Data Recovery didn't help much. We need to get the virtual disk 
file back and up.


Do you know somebody who knows somebody who can deal with this issue ?

Please contact me at rrazmkhah at ltpsn.org

I look forward to receiving some cost estimates.

Best regards,

Remi Razmkhah

--
+33 6 81 96 65 45
Service Informatique
Lycée Technique Privé Saint-Nicolas
Paris 06

Re: [Qemu-devel] [PATCH v2 0/3] ivshmem: MSI bug fixes

2017-11-19 Thread geoff--- via Qemu-devel

I just updated to the latest build and applied this patch set, now on VM 
reset the qemu crashes with the following assert:


ivshmem.c:467: ivshmem_add_kvm_msi_virq: Assertion 
`!s->msi_vectors[vector].pdev' failed.


On 2017-11-15 18:31, Ladi Prosek wrote:

Fixes bugs in the ivshmem device implementation uncovered with the new
Windows ivshmem driver:
https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/ivshmem

v1->v2:
* Patch 1 - added reproducer info to commit message (Markus)
* Patch 2 - restructured conditionals, fixed comment formatting 
(Markus)

* Patch 3 - added reproducer info to commit message (Markus)

Ladi Prosek (3):
  ivshmem: Don't update non-existent MSI routes
  ivshmem: Always remove irqfd notifiers
  ivshmem: Improve MSI irqfd error handling

 hw/misc/ivshmem.c | 77 
+--

 1 file changed, 58 insertions(+), 19 deletions(-)

Re: [Qemu-devel] [RFC for-3.2 PATCH 0/7] pcie: Enhanced link speed and width support

2018-11-14 Thread geoff--- via Qemu-devel

I can confirm that these patches work as expected. Thank you kindly Alex 
for your hard work!


Tested-by: Geoffrey McRae 

On 2018-11-15 07:50, Alex Williamson wrote:

QEMU exposes gen1 PCI-express interconnect devices supporting only
2.5GT/s and x1 width.  It might not seem obvious that a virtual
bandwidth limitation can result in a real performance degradation, but
it's been reported that in some configurations assigned GPUs might not
scale their link speed up to the maximum supported value if the
downstream port above it only advertises limited link support.

As proposed[1] this series effectively implements virtual link
negotiation on downstream ports and enhances the generic PCIe root
port to allow user configurable speeds and widths.  The "negotiation"
simply mirrors the link status of the connected downstream device
providing the appearance of dynamic link speed scaling to match the
endpoint device.  Not yet implemented from the proposal is support
for globally updating defaults based on machine type, though the
foundation is provided here by allowing supporting PCIESlots to
implement an instance_init callback which can call into a common
helper for this.

I have not specifically tested migration with this, but we already
consider LNKSTA to be dynamic and the other changes implemented here
are static config space changes with no changes being implemented for
devices using default values, ie. they should be compatible by virtue
of existing config space migration support.

I think I've covered the required link related registers to support
PCIe 4.0, but please let me know if I've missed any.

Testing and feedback appreciated, patch 6/7 provides example qemu:arg
options and requirements to use with existing libvirt.  Native libvirt
support TBD.  Thanks,

Alex

[1] https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg03086.html

---

Alex Williamson (7):
  pcie: Create enums for link speed and width
  pci: Sync PCIe downstream port LNKSTA on read
  qapi: Define PCIe link speed and width properties
  pcie: Add link speed and width fields to PCIESlot
  pcie: Fill PCIESlot link fields to support higher speeds and 
widths
  pcie: Allow generic PCIe root port to specify link speed and 
width

  vfio/pci: Remove PCIe Link Status emulation


 hw/core/qdev-properties.c  |  178 


 hw/pci-bridge/gen_pcie_root_port.c |2
 hw/pci-bridge/pcie_root_port.c |   14 +++
 hw/pci/pci.c   |4 +
 hw/pci/pcie.c  |  118 +++-
 hw/vfio/pci.c  |9 --
 include/hw/pci/pci.h   |   13 +++
 include/hw/pci/pcie.h  |1
 include/hw/pci/pcie_port.h |4 +
 include/hw/pci/pcie_regs.h |   23 -
 include/hw/qdev-properties.h   |8 ++
 qapi/common.json   |   42 
 12 files changed, 404 insertions(+), 12 deletions(-)

Re: [Qemu-devel] [PATCH v3] vmdk: align end of file to a sector boundary

2018-10-07 Thread yuchenlin via Qemu-devel


On 2018-10-08 10:38, Fam Zheng wrote:

On Fri, 10/05 10:00, yuchenlin wrote:

Ping?


Hi,

This was merged as 51b3c6b73acae1e3fd3c7d441fc86dd17356695f.

Fam



Hi,

Thank you for your information.

yuchenlin



On 2018-09-13 16:34, Fam Zheng wrote:
> On Thu, 09/13 16:29, yuchen...@synology.com wrote:
> > From: yuchenlin 
> >
> > There is a rare case which the size of last compressed cluster
> > is larger than the cluster size, which will cause the file is
> > not aligned at the sector boundary.
> >
> > There are three reasons to do it. First, if vmdk doesn't align at
> > the sector boundary, there may be many undefined behaviors,
> > such as, in vbox it will show VMDK: Compressed image is corrupted
> > 'syno-vm-disk1.vmdk' (VERR_ZIP_CORRUPTED) when we try to import an
> > ova with unaligned vmdk. Second, all the cluster_sector is aligned
> > to sector, the last one should be like this, too. Third, it ease
> > reading with sector based I/Os.
> >
> > Signed-off-by: yuchenlin 
>
> Reviewed-by: Fam Zheng

[Qemu-devel] [PATCH] vhost-scsi: prevent using uninitialized vqs

2018-10-12 Thread yuchenlin--- via Qemu-devel

From: yuchenlin 

There are 3 virtqueues (ctrl, event and cmd) for virtio scsi device,
but seabios will only set the physical address for the 3rd one (cmd).
Then in vhost_virtqueue_start(), virtio_queue_get_desc_addr()
will be 0 for ctrl and event vq.

In this case, ctrl and event vq are not initialized.
vhost_verify_ring_mappings may use uninitialized vhost_virtqueue
such that vhost_verify_ring_part_mapping returns ENOMEM.

When encountered this problem, we got the following logs:

qemu-system-x86_64: Unable to map available ring for ring 0
qemu-system-x86_64: Verify ring failure on region 0

Signed-off-by: Forrest Liu 
Signed-off-by: yuchenlin 
---
 hw/scsi/vhost-scsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index becf550085..7f21b4f9d6 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -183,7 +183,7 @@ static void vhost_scsi_realize(DeviceState *dev, Error 
**errp)
 }
 
 vsc->dev.nvqs = VHOST_SCSI_VQ_NUM_FIXED + vs->conf.num_queues;
-vsc->dev.vqs = g_new(struct vhost_virtqueue, vsc->dev.nvqs);
+vsc->dev.vqs = g_new0(struct vhost_virtqueue, vsc->dev.nvqs);
 vsc->dev.vq_index = 0;
 vsc->dev.backend_features = 0;
 
-- 
2.18.0

Re: [Qemu-devel] [PATCH] vhost-scsi: prevent using uninitialized vqs

2018-10-21 Thread yuchenlin via Qemu-devel


Ping?

On 2018-10-12 17:07, yuchen...@synology.com wrote:

From: yuchenlin 

There are 3 virtqueues (ctrl, event and cmd) for virtio scsi device,
but seabios will only set the physical address for the 3rd one (cmd).
Then in vhost_virtqueue_start(), virtio_queue_get_desc_addr()
will be 0 for ctrl and event vq.

In this case, ctrl and event vq are not initialized.
vhost_verify_ring_mappings may use uninitialized vhost_virtqueue
such that vhost_verify_ring_part_mapping returns ENOMEM.

When encountered this problem, we got the following logs:

qemu-system-x86_64: Unable to map available ring for ring 0
qemu-system-x86_64: Verify ring failure on region 0

Signed-off-by: Forrest Liu 
Signed-off-by: yuchenlin 
---
 hw/scsi/vhost-scsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index becf550085..7f21b4f9d6 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -183,7 +183,7 @@ static void vhost_scsi_realize(DeviceState *dev,
Error **errp)
 }

 vsc->dev.nvqs = VHOST_SCSI_VQ_NUM_FIXED + vs->conf.num_queues;
-vsc->dev.vqs = g_new(struct vhost_virtqueue, vsc->dev.nvqs);
+vsc->dev.vqs = g_new0(struct vhost_virtqueue, vsc->dev.nvqs);
 vsc->dev.vq_index = 0;
 vsc->dev.backend_features = 0;

[Qemu-devel] [PATCH] vga_int: remove unused function protype

2018-10-22 Thread yuchenlin--- via Qemu-devel

From: yuchenlin 

Signed-off-by: yuchenlin 
---
 hw/display/vga_int.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/display/vga_int.h b/hw/display/vga_int.h
index 6e4fa48a79..55c418eab5 100644
--- a/hw/display/vga_int.h
+++ b/hw/display/vga_int.h
@@ -166,7 +166,6 @@ MemoryRegion *vga_init_io(VGACommonState *s, Object *obj,
   const MemoryRegionPortio **vbe_ports);
 void vga_common_reset(VGACommonState *s);
 
-void vga_sync_dirty_bitmap(VGACommonState *s);
 void vga_dirty_log_start(VGACommonState *s);
 void vga_dirty_log_stop(VGACommonState *s);
 
-- 
2.18.0

Re: [Qemu-devel] [PATCH] vga_int: remove unused function protype

2018-10-29 Thread yuchenlin via Qemu-devel


On 2018-10-29 17:44, Gerd Hoffmann wrote:

On Mon, Oct 22, 2018 at 04:00:53PM +0800, yuchen...@synology.com wrote:

From: yuchenlin 

Signed-off-by: yuchenlin 
---
 hw/display/vga_int.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/display/vga_int.h b/hw/display/vga_int.h
index 6e4fa48a79..55c418eab5 100644
--- a/hw/display/vga_int.h
+++ b/hw/display/vga_int.h
@@ -166,7 +166,6 @@ MemoryRegion *vga_init_io(VGACommonState *s, 
Object *obj,

   const MemoryRegionPortio **vbe_ports);
 void vga_common_reset(VGACommonState *s);

-void vga_sync_dirty_bitmap(VGACommonState *s);
 void vga_dirty_log_start(VGACommonState *s);
 void vga_dirty_log_stop(VGACommonState *s);


Added to vga queue.

thanks,
  Gerd


Hi, Gerd

Laurent has sent a pull request for this trivial commit.
See: 
http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05896.html


Thanks,
yuchenlin

Re: [Qemu-devel] [PATCH v3] vmdk: align end of file to a sector boundary

2018-10-04 Thread yuchenlin via Qemu-devel


Ping?

On 2018-09-13 16:34, Fam Zheng wrote:

On Thu, 09/13 16:29, yuchen...@synology.com wrote:

From: yuchenlin 

There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.

There are three reasons to do it. First, if vmdk doesn't align at
the sector boundary, there may be many undefined behaviors,
such as, in vbox it will show VMDK: Compressed image is corrupted
'syno-vm-disk1.vmdk' (VERR_ZIP_CORRUPTED) when we try to import an
ova with unaligned vmdk. Second, all the cluster_sector is aligned
to sector, the last one should be like this, too. Third, it ease
reading with sector based I/Os.

Signed-off-by: yuchenlin 


Reviewed-by: Fam Zheng

Re: [Qemu-devel] [Qemu-block] [PATCH] dmg: Fixing wrong dmg block type value for block terminator.

2019-01-02 Thread yuchenlin via Qemu-devel


On 2018-12-28 22:50, Julio Faracco wrote:

This is a trivial patch to fix a wrong value for block terminator.
The old value was 0x7fff which is wrong. It was not affecting the
code because QEMU dmg block is not handling block terminator right now.
Neverthless, it should be fixed.

Signed-off-by: Julio Faracco 


Reviewed-by: yuchenlin 


---
 block/dmg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/dmg.c b/block/dmg.c
index 50e91aef6d..2c806e3389 100644
--- a/block/dmg.c
+++ b/block/dmg.c
@@ -54,7 +54,7 @@ enum {
 UDBZ,
 ULFO,
 UDCM = 0x7ffe, /* Comments */
-UDLE   /* Last Entry */
+UDLE = 0x  /* Last Entry */
 };

 static int dmg_probe(const uint8_t *buf, int buf_size, const char 
*filename)

[Qemu-devel] [PATCH] vmdk: align end of file to a sector boundary

2018-08-27 Thread yuchenlin--- via Qemu-devel

From: yuchenlin 

There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.

Signed-off-by: yuchenlin 
---
 block/vmdk.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/block/vmdk.c b/block/vmdk.c
index a9d0084e36..a8ae7c65d2 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -1698,6 +1698,24 @@ static int coroutine_fn
 vmdk_co_pwritev_compressed(BlockDriverState *bs, uint64_t offset,
uint64_t bytes, QEMUIOVector *qiov)
 {
+if (bytes == 0) {
+/* align end of file to a sector boundary. */
+BDRVVmdkState *s = bs->opaque;
+int i, ret;
+int64_t length;
+
+for (i = 0; i < s->num_extents; i++) {
+length = bdrv_getlength(s->extents[i].file->bs);
+if (length < 0) {
+return length;
+}
+ret = bdrv_truncate(s->extents[i].file, length, PREALLOC_MODE_OFF, 
NULL);
+if (ret < 0) {
+return ret;
+}
+}
+return 0;
+}
 return vmdk_co_pwritev(bs, offset, bytes, qiov, 0);
 }
 
-- 
2.17.0

[Qemu-devel] [Bug 1790260] [NEW] binfmt support not working for x86 host and x86_64 guest

2018-08-31 Thread elypter via Qemu-devel

Public bug reported:

this is a problem in the qemu-binfmt-conf.sh script and maybe somewhere
else. the version i checked is the current github mirror
https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh

i am running linux mint 19 32bit on a 32bit x86 cpu and i want to run
some applications that are only available as x86_64 packages. i use
multiarch and qemu and it works for simple applications like cacafire.
however i want to run the application natively from the shell without
having to use qemu-x86_64 . i also installed the binfmt-support
package. when i run update-binfmts --display then an extry for x86_64 is
missing and transparent execution is not working.

the problem seems to be in the qemu-binfmt-conf.sh script. it disables
the creation of entries for cpus of the same family. this is not a
problem if you are using a 64bit cpu because 32bit binaries run on it
natively but it doesnt work in the opposite way. hacking line 310 from

 if [ "$host_family" != "$family" ] ; then

to

 if [ "$cpu" = "x86_64" ] || [ "$host_family" != "$family" ] ;
then

and running it with the --systemd ALL parameter causes a x86_64 config
file to be created. it still doesnt work but that might have different
causes.

** Affects: qemu
 Importance: Undecided
 Status: New

** Description changed:

  this is a problem in the qemu-binfmt-conf.sh script and maybe somewhere
  else. the version i checked is the current github mirror
  https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh
  
  i am running linux mint 19 32bit on a 32bit x86 cpu and i want to run
  some applications that are only available as x86_64 packages. i use
  multiarch and qemu and it works for simple applications like cacafire.
  however i want to run the application natively from the shell without
  having to use qemu-x86_64 . i also installed the binfmt-support
  package. when i run update-binfmts --display then an extry for x86_64 is
  missing and transparent execution is not working.
  
  the problem seems to be in the qemu-binfmt-conf.sh script. it disables
  the creation of entries for cpus of the same family. this is not a
  problem if you are using a 64bit cpu because 32bit binaries run on it
- natively but it doesnt work in the opposite way. hacking line 310 to
+ natively but it doesnt work in the opposite way. hacking line 310 from
  
-  if [ "$cpu" = "x86_64" ] || [ "$host_family" != "$family" ] ;
+  if [ "$host_family" != "$family" ] ; then
+ 
+ to
+ 
+  if [ "$cpu" = "x86_64" ] || [ "$host_family" != "$family" ] ;
  then
  
  and running it with the --systemd ALL parameter causes a x86_64 config
  file to be created. it still doesnt work but that might have different
  causes.

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

Title:
  binfmt support not working for x86 host and x86_64 guest

Status in QEMU:
  New

Bug description:
  this is a problem in the qemu-binfmt-conf.sh script and maybe
  somewhere else. the version i checked is the current github mirror
  https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh

  i am running linux mint 19 32bit on a 32bit x86 cpu and i want to run
  some applications that are only available as x86_64 packages. i use
  multiarch and qemu and it works for simple applications like cacafire.
  however i want to run the application natively from the shell without
  having to use qemu-x86_64 . i also installed the binfmt-support
  package. when i run update-binfmts --display then an extry for x86_64
  is missing and transparent execution is not working.

  the problem seems to be in the qemu-binfmt-conf.sh script. it disables
  the creation of entries for cpus of the same family. this is not a
  problem if you are using a 64bit cpu because 32bit binaries run on it
  natively but it doesnt work in the opposite way. hacking line 310 from

   if [ "$host_family" != "$family" ] ; then

  to

   if [ "$cpu" = "x86_64" ] || [ "$host_family" != "$family" ] ;
  then

  and running it with the --systemd ALL parameter causes a x86_64 config
  file to be created. it still doesnt work but that might have different
  causes.

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

Re: [Qemu-devel] [PATCH] vmdk: align end of file to a sector boundary

2018-09-04 Thread yuchenlin via Qemu-devel

Ping!

yuchen...@synology.com 於 2018-08-28 11:18 寫道：
> From: yuchenlin  There is a rare case which the size 
> of last compressed cluster is larger than the cluster size, which will cause 
> the file is not aligned at the sector boundary. Signed-off-by: yuchenlin 
>  --- block/vmdk.c | 18 ++ 1 file 
> changed, 18 insertions(+) diff --git a/block/vmdk.c b/block/vmdk.c index 
> a9d0084e36..a8ae7c65d2 100644 --- a/block/vmdk.c +++ b/block/vmdk.c @@ 
> -1698,6 +1698,24 @@ static int coroutine_fn 
> vmdk_co_pwritev_compressed(BlockDriverState *bs, uint64_t offset, uint64_t 
> bytes, QEMUIOVector *qiov) { + if (bytes == 0) { + /* align end of file to a 
> sector boundary. */ + BDRVVmdkState *s = bs->opaque; + int i, ret; + int64_t 
> length; + + for (i = 0; i < s->num_extents; i++) { + length = 
> bdrv_getlength(s->extents[i].file->bs); + if (length < 0) { + return length; 
> + } + ret = bdrv_truncate(s->extents[i].file, length, PREALLOC_MODE_OFF, 
> NULL); + if (ret < 0) { + return ret; + } + } + return 0; + } return 
> vmdk_co_pwritev(bs, offset, bytes, qiov, 0); } -- 2.17.0

Re: [Qemu-devel] [PATCH] vmdk: align end of file to a sector boundary

2018-09-12 Thread yuchenlin via Qemu-devel



Fam Zheng  於 2018-09-12 17:34 寫道：
> On Tue, 08/28 11:17, yuchen...@synology.com wrote: > From: yuchenlin 
>  > > There is a rare case which the size of last 
> compressed cluster > is larger than the cluster size, which will cause the 
> file is > not aligned at the sector boundary. I don't understand. Doesn't it 
> mean that if you force the alignment by truncating out the extra bytes, some 
> data is lost?   

You can take qcow2_co_pwritev_compressed in block/qcow2.c as an example.
The bdrv_getlength will return the length in bytes which is always a multiple 
of BDRV_SECTOR_SIZE.
After truncates this size, the vmdk is extended to align sector size.
> > > Signed-off-by: yuchenlin  > --- > block/vmdk.c | 
> > > 18 ++ > 1 file changed, 18 insertions(+) > > diff --git 
> > > a/block/vmdk.c b/block/vmdk.c > index a9d0084e36..a8ae7c65d2 100644 > --- 
> > > a/block/vmdk.c > +++ b/block/vmdk.c > @@ -1698,6 +1698,24 @@ static int 
> > > coroutine_fn > vmdk_co_pwritev_compressed(BlockDriverState *bs, uint64_t 
> > > offset, > uint64_t bytes, QEMUIOVector *qiov) > { > + if (bytes == 0) { 
> > > Where is this bytes == 0 condition from?

From the end of convert_do_copy in qemu-img.c.

if (s->compressed && !s->ret) {
/* signal EOF to align */
ret = blk_pwrite_compressed(s->target, 0, NULL, 0);
if (ret < 0) {
return ret;
}
}

It signals the EOF to the block driver.
> > + /* align end of file to a sector boundary. */ > + BDRVVmdkState *s = 
> > bs->opaque; > + int i, ret; > + int64_t length; > + > + for (i = 0; i < 
> > s->num_extents; i++) { > + length = bdrv_getlength(s->extents[i].file->bs); 
> > > + if (length < 0) { > + return length; > + } > + ret = 
> > bdrv_truncate(s->extents[i].file, length, PREALLOC_MODE_OFF, NULL); > + if 
> > (ret < 0) { > + return ret; > + } > + } > + return 0; > + } > return 
> > vmdk_co_pwritev(bs, offset, bytes, qiov, 0); > } > > -- > 2.17.0 > Fam


yuchenlin

Re: [Qemu-devel] [PATCH] vmdk: align end of file to a sector boundary

2018-09-12 Thread yuchenlin via Qemu-devel


On 2018-09-12 19:54, Fam Zheng wrote:

On Tue, 08/28 11:17, yuchen...@synology.com wrote:

From: yuchenlin 

There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.

Signed-off-by: yuchenlin 
---
 block/vmdk.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/block/vmdk.c b/block/vmdk.c
index a9d0084e36..a8ae7c65d2 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -1698,6 +1698,24 @@ static int coroutine_fn
 vmdk_co_pwritev_compressed(BlockDriverState *bs, uint64_t offset,
uint64_t bytes, QEMUIOVector *qiov)
 {
+if (bytes == 0) {
+/* align end of file to a sector boundary. */
+BDRVVmdkState *s = bs->opaque;
+int i, ret;
+int64_t length;
+
+for (i = 0; i < s->num_extents; i++) {
+length = bdrv_getlength(s->extents[i].file->bs);
+if (length < 0) {
+return length;
+}


Could you add "length = QEMU_ALIGN_UP(length, BDRV_SECTOR_SIZE);" to 
show the

intention more clearly?

Fam



Thank you for your effort, I will do it.

yuchenlin

+ret = bdrv_truncate(s->extents[i].file, length, 
PREALLOC_MODE_OFF, NULL);

+if (ret < 0) {
+return ret;
+}
+}
+return 0;
+}
 return vmdk_co_pwritev(bs, offset, bytes, qiov, 0);
 }

--
2.17.0

[Qemu-devel] [PATCH v2] vmdk: align end of file to a sector boundary

2018-09-12 Thread yuchenlin--- via Qemu-devel

From: yuchenlin 

There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.

Signed-off-by: yuchenlin 
---
v1 -> v2:
* Add more detail comment.
* Add QEMU_ALIGN_UP to show the intention more clearly.
* Add newline in the end of bdrv_truncate.

thanks

 block/vmdk.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/block/vmdk.c b/block/vmdk.c
index a9d0084e36..2c9e86d98f 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -1698,6 +1698,27 @@ static int coroutine_fn
 vmdk_co_pwritev_compressed(BlockDriverState *bs, uint64_t offset,
uint64_t bytes, QEMUIOVector *qiov)
 {
+if (bytes == 0) {
+/* The caller will write bytes 0 to signal EOF.
+ * When receive it, we align EOF to a sector boundary. */
+BDRVVmdkState *s = bs->opaque;
+int i, ret;
+int64_t length;
+
+for (i = 0; i < s->num_extents; i++) {
+length = bdrv_getlength(s->extents[i].file->bs);
+if (length < 0) {
+return length;
+}
+length = QEMU_ALIGN_UP(length, BDRV_SECTOR_SIZE);
+ret = bdrv_truncate(s->extents[i].file, length,
+PREALLOC_MODE_OFF, NULL);
+if (ret < 0) {
+return ret;
+}
+}
+return 0;
+}
 return vmdk_co_pwritev(bs, offset, bytes, qiov, 0);
 }
 
-- 
2.18.0

Re: [Qemu-devel] [PATCH v2] vmdk: align end of file to a sector boundary

2018-09-13 Thread yuchenlin via Qemu-devel


On 2018-09-13 10:54, Fam Zheng wrote:

On Thu, 09/13 10:31, yuchen...@synology.com wrote:

From: yuchenlin 

There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.


The code looks good to me. Can you also explain why it is important to 
align

file size to sector boundary in the comment?

Fam



In my opinion, there are three reasons to do it. First, if vmdk doesn't 
align at the sector boundary, there may be many undefined behaviors, 
such as in vbox it will show VMDK: Compressed image is corrupted 
'88-disk1.vmdk' (VERR_ZIP_CORRUPTED) when we try to import an ova with 
unaligned vmdk. Second, all the cluster_sector is aligned
to sector, the last one should be like this, too. Third, it ease reading 
with sector based I/Os.


What do you think?

yuchenlin



Signed-off-by: yuchenlin 
---
v1 -> v2:
* Add more detail comment.
* Add QEMU_ALIGN_UP to show the intention more clearly.
* Add newline in the end of bdrv_truncate.

thanks

 block/vmdk.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/block/vmdk.c b/block/vmdk.c
index a9d0084e36..2c9e86d98f 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -1698,6 +1698,27 @@ static int coroutine_fn
 vmdk_co_pwritev_compressed(BlockDriverState *bs, uint64_t offset,
uint64_t bytes, QEMUIOVector *qiov)
 {
+if (bytes == 0) {
+/* The caller will write bytes 0 to signal EOF.
+ * When receive it, we align EOF to a sector boundary. */
+BDRVVmdkState *s = bs->opaque;
+int i, ret;
+int64_t length;
+
+for (i = 0; i < s->num_extents; i++) {
+length = bdrv_getlength(s->extents[i].file->bs);
+if (length < 0) {
+return length;
+}
+length = QEMU_ALIGN_UP(length, BDRV_SECTOR_SIZE);
+ret = bdrv_truncate(s->extents[i].file, length,
+PREALLOC_MODE_OFF, NULL);
+if (ret < 0) {
+return ret;
+}
+}
+return 0;
+}
 return vmdk_co_pwritev(bs, offset, bytes, qiov, 0);
 }

--
2.18.0

[Qemu-devel] [PATCH v3] vmdk: align end of file to a sector boundary

2018-09-13 Thread yuchenlin--- via Qemu-devel

From: yuchenlin 

There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.

There are three reasons to do it. First, if vmdk doesn't align at
the sector boundary, there may be many undefined behaviors,
such as, in vbox it will show VMDK: Compressed image is corrupted
'syno-vm-disk1.vmdk' (VERR_ZIP_CORRUPTED) when we try to import an
ova with unaligned vmdk. Second, all the cluster_sector is aligned
to sector, the last one should be like this, too. Third, it ease
reading with sector based I/Os.

Signed-off-by: yuchenlin 
---
v2 -> v3:
* Update commit message

thanks

 block/vmdk.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/block/vmdk.c b/block/vmdk.c
index a9d0084e36..2c9e86d98f 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -1698,6 +1698,27 @@ static int coroutine_fn
 vmdk_co_pwritev_compressed(BlockDriverState *bs, uint64_t offset,
uint64_t bytes, QEMUIOVector *qiov)
 {
+if (bytes == 0) {
+/* The caller will write bytes 0 to signal EOF.
+ * When receive it, we align EOF to a sector boundary. */
+BDRVVmdkState *s = bs->opaque;
+int i, ret;
+int64_t length;
+
+for (i = 0; i < s->num_extents; i++) {
+length = bdrv_getlength(s->extents[i].file->bs);
+if (length < 0) {
+return length;
+}
+length = QEMU_ALIGN_UP(length, BDRV_SECTOR_SIZE);
+ret = bdrv_truncate(s->extents[i].file, length,
+PREALLOC_MODE_OFF, NULL);
+if (ret < 0) {
+return ret;
+}
+}
+return 0;
+}
 return vmdk_co_pwritev(bs, offset, bytes, qiov, 0);
 }
 
-- 
2.18.0

[Qemu-devel] [Bug 1781211] [NEW] HAXM acceleration does not work at all.

2018-07-11 Thread Dmitriy via Qemu-devel

Public bug reported:

I have qemu windows build 2.12.90, haxm 7.2.0. Ubuntu, nor arch linux does not
works when i turn on hax acceleration. Permanent kernel panics, black screen
freezing and other crashes happens when i run qemu.
Qemu crashed with hax - when i ran it from iso. It crashed on already installed
system - it's not matters.

Versions:
archlinux-2018.07.01-x86_64
ubuntu-18.04-live-server-amd64.iso

I run qemu-system-x86_64.exe binary.

My CPU:
core i7 2600k

See screenshot

** Affects: qemu
Importance: Undecided
Status: New

** Tags: hax haxm windows

** Attachment added: "2018-07-11_15-49-15.png"

https://bugs.launchpad.net/bugs/1781211/+attachment/5162388/+files/2018-07-11_15-49-15.png

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

Title:
HAXM acceleration does not work at all.

Status in QEMU:
New

Bug description:
I have qemu windows build 2.12.90, haxm 7.2.0. Ubuntu, nor arch linux does
not works when i turn on hax acceleration. Permanent kernel panics, black
screen freezing and other crashes happens when i run qemu.
Qemu crashed with hax - when i ran it from iso. It crashed on already
installed system - it's not matters.

Versions:
archlinux-2018.07.01-x86_64
ubuntu-18.04-live-server-amd64.iso

I run qemu-system-x86_64.exe binary.

My CPU:
core i7 2600k

See screenshot

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

[Qemu-devel] [Bug 1781211] Re: HAXM acceleration does not work at all.

2018-07-11 Thread Dmitriy via Qemu-devel

After some time I decided it is haxm bug - so i created the same issue
on haxm project too

https://github.com/intel/haxm/issues/74

** Bug watch added: github.com/intel/haxm/issues #74
   https://github.com/intel/haxm/issues/74

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

Title:
  HAXM acceleration does not work at all.

Status in QEMU:
  New

Bug description:
  I have qemu windows build 2.12.90, haxm 7.2.0. Ubuntu, nor arch linux does 
not works when i turn on hax acceleration. Permanent kernel panics, black 
screen freezing and other crashes happens when i run qemu.
  Qemu crashed with hax - when i ran it from iso. It crashed on already 
installed system - it's not matters. 

  Versions:
  archlinux-2018.07.01-x86_64
  ubuntu-18.04-live-server-amd64.iso

  I run qemu-system-x86_64.exe binary.

  My CPU:
  core i7 2600k

  See screenshot

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

[Qemu-devel] [Bug 1766896] [NEW] qemu-system-arm segfault in arm_v7m_mmu_idx_for_secstate

2018-04-25 Thread fenugrec via Qemu-devel

   loadvm = 
machine_class = 
cpu_model = 
vga_model = 
qtest_chrdev = 
qtest_log = 
pid_file = 
incoming = 
userconfig = 
nographic = 
display_type = 
display_remote = 
log_mask = 
log_file = 
trace_file = 
maxram_size = 
ram_slots = 
vmstate_dump_file = 
main_loop_err = 0x0
err = 0x0
list_data_dirs = 
dirs = 
bdo_queue = {sqh_first = 0x0, sqh_last = 0xb918}
__func__ = "main"

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

Title:
  qemu-system-arm segfault in arm_v7m_mmu_idx_for_secstate

Status in QEMU:
  New

Bug description:
  Attempting to emulate some baremetal ARM cortex-M* firmware with gdb
  causes a segfault every time.

  qemu invocation:
  qemu-system-arm -machine none -cpu cortex-m3 -nographic -monitor null -serial 
null -s -S -device loader,file=firmware.elf

  qemu seems to startup fine with that command. Segfault happens as soon
  as I connect from another console with

  arm-none-eabi-gdb firmware.elf
  > target remote localhost:1234
  # qemu segfaults, and kills arm-none-eabi-gdb along with it

  Here's a bt from qemu-system-arm :

  *
  #0  armv7m_nvic_neg_prio_requested (opaque=0x0, secure=false)
  at /home/sac/qemu/src/qemu/hw/intc/armv7m_nvic.c:383
  s = 0x0
  #1  0x006e4806 in arm_v7m_mmu_idx_for_secstate (secstate=, 
env=0xb620263c)
  at /home/sac/qemu/src/qemu/target/arm/cpu.h:2345
  el = 
  mmu_idx = ARMMMUIdx_MPriv
  el = 
  mmu_idx = 
  #2  cpu_mmu_index (ifetch=false, env=0xb620263c) at 
/home/sac/qemu/src/qemu/target/arm/cpu.h:2358
  mmu_idx = 
  el = 
  ifetch = 
  env = 0xb620263c
  el = 
  mmu_idx = 
  el = 
  el = 
  mmu_idx = 
  #3  arm_cpu_get_phys_page_attrs_debug (cs=0xb61fe480, addr=0, 
attrs=0xbfffc668)
  at /home/sac/qemu/src/qemu/target/arm/helper.c:9858
  cpu = 0xb61fe480
  __func__ = "arm_cpu_get_phys_page_attrs_debug"
  env = 0xb620263c
  phys_addr = 6402535376434480864
  page_size = 5
  prot = -1239242724
  ret = 
  fsr = 4294967041
  fi = {s2addr = 0, stage2 = false, s1ptw = false, ea = false}
  mmu_idx = 
  #4  0x005729d1 in cpu_get_phys_page_attrs_debug (attrs=, 
addr=, 
  cpu=) at /home/sac/qemu/src/qemu/include/qom/cpu.h:580
  cc = 
  cc = 
  #5  cpu_memory_rw_debug (cpu=0xb61fe480, addr=0, buf=0xbfffd6dc "", len=4, 
is_write=0)
  at /home/sac/qemu/src/qemu/exec.c:3524
  asidx = 
  attrs = {unspecified = 0, secure = 0, user = 0, requester_id = 15525}
  l = 
  phys_addr = 
  page = 0
  __PRETTY_FUNCTION__ = "cpu_memory_rw_debug"
  #6  0x005b4c5e in target_memory_rw_debug (is_write=false, len=4, 
buf=, addr=0, 
  cpu=0xb61fe480) at /home/sac/qemu/src/qemu/gdbstub.c:56
  cc = 
  cc = 
  #7  gdb_handle_packet (s=s@entry=0xb6229800, 
line_buf=line_buf@entry=0xb6229810 "m0,4")
  at /home/sac/qemu/src/qemu/gdbstub.c:1109
  cpu = 
  cc = 
  p = 0xb6229813 "4"
  thread = 
  ch = 
  reg_size = 
  type = 
  res = 
  buf = "m1\000", '\060' , 
"d3010040\000t modification,\n are permitted in any medium 
without royalt"...
  mem_buf = '\000' , 
"\377\377\377\377\000\000\000\000\323\001\000@", '\000' ...
  registers = 
  addr = 0
  len = 4
  __func__ = "gdb_handle_packet"
  #8  0x005b55b3 in gdb_read_byte (ch=100, s=0xb6229800) at 
/home/sac/qemu/src/qemu/gdbstub.c:1664
  reply = 43 '+'
  reply = 
  repeat = 
  #9  gdb_chr_receive (opaque=, buf=, 
size=)
  at /home/sac/qemu/src/qemu/gdbstub.c:1868
  i = 
  #10 0x00980319 in tcp_chr_read (chan=0xb6c86200, cond=G_IO_IN, 
opaque=0xb63fc6e0)
  at chardev/char-socket.c:440
  chr = 
  __func__ = "tcp_chr_read"
  s = 0xb63fc6e0
  buf = 
"$m0,4#fddInfo#c8read:arm-core.xml:0,ffb#08+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df\363\377\377\000\000\000\000\274\354\377\277",
 '\000' , "\272\356\377 \274\354\377\277", '\000' , "\373\377\377\377\005\000\000\000"...
  len = 
  size = 
  #11 0xb7808c44 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
  No symbol table info

[Qemu-devel] [Bug 1766896] Re: qemu-system-arm segfault in arm_v7m_mmu_idx_for_secstate

2018-04-25 Thread fenugrec via Qemu-devel

follow-up to IRC discussions with stsquad and danpb : the problem is
"-machine none" which prevents all the data structures from being
initialized properly.

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

Title:
  qemu-system-arm segfault in arm_v7m_mmu_idx_for_secstate

Status in QEMU:
  New

Bug description:
  Attempting to emulate some baremetal ARM cortex-M* firmware with gdb
  causes a segfault every time.

  qemu invocation:
  qemu-system-arm -machine none -cpu cortex-m3 -nographic -monitor null -serial 
null -s -S -device loader,file=firmware.elf

  qemu seems to startup fine with that command. Segfault happens as soon
  as I connect from another console with

  arm-none-eabi-gdb firmware.elf
  > target remote localhost:1234
  # qemu segfaults, and kills arm-none-eabi-gdb along with it

  Here's a bt from qemu-system-arm :

  *
  #0  armv7m_nvic_neg_prio_requested (opaque=0x0, secure=false)
  at /home/sac/qemu/src/qemu/hw/intc/armv7m_nvic.c:383
  s = 0x0
  #1  0x006e4806 in arm_v7m_mmu_idx_for_secstate (secstate=, 
env=0xb620263c)
  at /home/sac/qemu/src/qemu/target/arm/cpu.h:2345
  el = 
  mmu_idx = ARMMMUIdx_MPriv
  el = 
  mmu_idx = 
  #2  cpu_mmu_index (ifetch=false, env=0xb620263c) at 
/home/sac/qemu/src/qemu/target/arm/cpu.h:2358
  mmu_idx = 
  el = 
  ifetch = 
  env = 0xb620263c
  el = 
  mmu_idx = 
  el = 
  el = 
  mmu_idx = 
  #3  arm_cpu_get_phys_page_attrs_debug (cs=0xb61fe480, addr=0, 
attrs=0xbfffc668)
  at /home/sac/qemu/src/qemu/target/arm/helper.c:9858
  cpu = 0xb61fe480
  __func__ = "arm_cpu_get_phys_page_attrs_debug"
  env = 0xb620263c
  phys_addr = 6402535376434480864
  page_size = 5
  prot = -1239242724
  ret = 
  fsr = 4294967041
  fi = {s2addr = 0, stage2 = false, s1ptw = false, ea = false}
  mmu_idx = 
  #4  0x005729d1 in cpu_get_phys_page_attrs_debug (attrs=, 
addr=, 
  cpu=) at /home/sac/qemu/src/qemu/include/qom/cpu.h:580
  cc = 
  cc = 
  #5  cpu_memory_rw_debug (cpu=0xb61fe480, addr=0, buf=0xbfffd6dc "", len=4, 
is_write=0)
  at /home/sac/qemu/src/qemu/exec.c:3524
  asidx = 
  attrs = {unspecified = 0, secure = 0, user = 0, requester_id = 15525}
  l = 
  phys_addr = 
  page = 0
  __PRETTY_FUNCTION__ = "cpu_memory_rw_debug"
  #6  0x005b4c5e in target_memory_rw_debug (is_write=false, len=4, 
buf=, addr=0, 
  cpu=0xb61fe480) at /home/sac/qemu/src/qemu/gdbstub.c:56
  cc = 
  cc = 
  #7  gdb_handle_packet (s=s@entry=0xb6229800, 
line_buf=line_buf@entry=0xb6229810 "m0,4")
  at /home/sac/qemu/src/qemu/gdbstub.c:1109
  cpu = 
  cc = 
  p = 0xb6229813 "4"
  thread = 
  ch = 
  reg_size = 
  type = 
  res = 
  buf = "m1\000", '\060' , 
"d3010040\000t modification,\n are permitted in any medium 
without royalt"...
  mem_buf = '\000' , 
"\377\377\377\377\000\000\000\000\323\001\000@", '\000' ...
  registers = 
  addr = 0
  len = 4
  __func__ = "gdb_handle_packet"
  #8  0x005b55b3 in gdb_read_byte (ch=100, s=0xb6229800) at 
/home/sac/qemu/src/qemu/gdbstub.c:1664
  reply = 43 '+'
  reply = 
  repeat = 
  #9  gdb_chr_receive (opaque=, buf=, 
size=)
  at /home/sac/qemu/src/qemu/gdbstub.c:1868
  i = 
  #10 0x00980319 in tcp_chr_read (chan=0xb6c86200, cond=G_IO_IN, 
opaque=0xb63fc6e0)
  at chardev/char-socket.c:440
  chr = 
  __func__ = "tcp_chr_read"
  s = 0xb63fc6e0
  buf = 
"$m0,4#fddInfo#c8read:arm-core.xml:0,ffb#08+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df\363\377\377\000\000\000\000\274\354\377\277",
 '\000' , "\272\356\377 \274\354\377\277", '\000' , "\373\377\377\377\005\000\000\000"...
  len = 
  size = 
  #11 0xb7808c44 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
  No symbol table info available.
  #12 0x009e14d2 in glib_pollfds_poll () at util/main-loop.c:214
  context = 0xb645f740
  pfds = 
  context = 
  pfds = 
  #13 os_host_main_loop_wait (timeout=) at util/main-loop.c:261
  context = 0xb645f740
  ret = 1
  spin_counter = 0
  context = 
  ret = 
  spin_counter = 0
  notified = false
  #14 main_loop_wait (nonblocking=0) at util/main-loop.c:515
  ret =

Re: [Qemu-devel] [PATCH v7 0/9] i386: Enable TOPOEXT to support hyperthreading on AMD CPU

2018-04-26 Thread geoff--- via Qemu-devel


Works well for me, thanks!

Tested-by: Geoffrey McRae 

On 2018-04-27 02:26, Babu Moger wrote:
This series enables the TOPOEXT feature for AMD CPUs. This is required 
to

support hyperthreading on kvm guests.

This addresses the issues reported in these bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1481253
https://bugs.launchpad.net/qemu/+bug/1703506

v7:
 Rebased on top of latest tree after 2.12 release and done few basic
tests. There are
 no changes except for few minor hunks. Hopefully this gets pulled
into 2.13 release.
 Please review, let me know of any feedback.

v6:
1.Fixed problem with patch#4(Add new property to control cache info).
The parameter
 legacy_cache should be "on" by default on machine type "pc-q35-2.10". 
This was

 found by Alexandr Iarygin.
2.Fixed the l3 cache size for EPYC based machines(patch#3). Also,
fixed the number of
 logical processors sharing the cache(patch#6). Only L3 cache is
shared by multiple
 cores but not L1 or L2. This was a bug while decoding. This was found
by Geoffrey McRae
 and he verified the fix.

v5:
 In this series I tried to address the feedback from Eduardo Habkost.
 The discussion thread is here.
 https://patchwork.kernel.org/patch/10299745/
 The previous thread is here.
 http://patchwork.ozlabs.org/cover/884885/

Reason for these changes.
 The cache properties for AMD family of processors have changed from
 previous releases. We don't want to display the new information on the
 old family of processors as this might cause compatibility issues.

Changes:
1.Based the patches on top of Eduardo's(patch#1) patch.
  Changed few things.
  Moved the Cache definitions to cpu.h file.
  Changed the CPUID_4 names to generic names.
2.Added a new propery "legacy-cache" in cpu object(patch#2). This can 
be
  used to display the old property even if the host supports the new 
cache

  properties.
3.Added cache information in X86CPUDefinition and CPUX86State
4.Patch 6-7 changed quite a bit from previous version does to new 
approach.

5.Addressed few issues with CPUID_8000_001d and CPUID_8000_001E.

v4:
1.Removed the checks under cpuid 0x801D leaf(patch #2). These check 
are

  not necessary. Found this during internal review.
2.Added CPUID_EXT3_TOPOEXT feature for all the 17 family(patch #4). 
This was

  found by Kash Pande during his testing.
3.Removed th hardcoded cpuid xlevel and dynamically extended if
CPUID_EXT3_TOPOEXT
  is supported(Suggested by Brijesh Singh).

v3:
1.Removed the patch #1. Radim mentioned that original typo problem is 
in

  linux kernel header. qemu is just copying those files.
2.In previous version, I used the cpuid 4 definitions for AMDs cpuid 
leaf
  0x801D. CPUID 4 is very intel specific and we dont want to expose 
those
  details under AMD. I have renamed some of these definitions as 
generic.
  These changes are in patch#1. Radim, let me know if this is what you 
intended.

3.Added assert to for core_id(Suggested by Radim Krčmář).
4.Changed the if condition under "L3 cache info"(Suggested by Gary 
Hook).

5.Addressed few more text correction and code cleanup(Suggested by
Thomas Lendacky).

v2:
  Fixed few more minor issues per Gary Hook's comments. Thank you Gary.
  Removed the patch#1. We need to handle the instruction cache 
associativity
  seperately. It varies based on the cpu family. I will comeback to 
that later.

  Added two more typo corrections in patch#1 and patch#5.

v1:
  Stanislav Lanci posted few patches earlier.
  https://patchwork.kernel.org/patch/10040903/

Rebased his patches with few changes.
1.Spit the patches into two, separating cpuid functions
  0x801D and 0x801E (Patch 2 and 3).
2.Removed the generic non-intel check and made a separate patch
  with some changes(Patch 5).
3.Fixed L3_N_SETS_AMD(from 4096 to 8192) based on 
CPUID_Fn801D_ECX_x03.


Added 2 more patches.
Patch 1. Fixes cache associativity.
Patch 4. Adds TOPOEXT feature on AMD EPYC CPU.


Babu Moger (8):
  i386: Add cache information in X86CPUDefinition
  i386: Initialize cache information for EPYC family processors
  i386: Add new property to control cache info
  i386: Use the statically loaded cache definitions
  i386: Populate AMD Processor Cache Information for cpuid 0x801D
  i386: Add support for CPUID_8000_001E for AMD
  i386: Enable TOPOEXT feature on AMD EPYC CPU
  i386: Remove generic SMT thread check

Eduardo Habkost (1):
  i386: Helpers to encode cache information consistently

 include/hw/i386/pc.h |   4 +
 target/i386/cpu.c| 736 
++-

 target/i386/cpu.h|  66 +
 target/i386/kvm.c|  29 +-
 4 files changed, 702 insertions(+), 133 deletions(-)

[Qemu-devel] [PATCH] slirp: fix ICMP handling on macOS hosts

2018-07-25 Thread aoates--- via Qemu-devel

From: Andrew Oates 

On Linux, SOCK_DGRAM+IPPROTO_ICMP sockets give only the ICMP packet when
read from.  On macOS, however, the socket acts like a SOCK_RAW socket
and includes the IP header as well.

This change strips the extra IP header from the received packet on macOS
before sending it to the guest.

Signed-off-by: Andrew Oates 
---
 slirp/ip_icmp.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/slirp/ip_icmp.c b/slirp/ip_icmp.c
index 0b667a429a..5fa67814f4 100644
--- a/slirp/ip_icmp.c
+++ b/slirp/ip_icmp.c
@@ -420,7 +420,15 @@ void icmp_receive(struct socket *so)
 icp = mtod(m, struct icmp *);
 
 id = icp->icmp_id;
-len = qemu_recv(so->s, icp, m->m_len, 0);
+len = qemu_recv(so->s, icp, M_ROOM(m), 0);
+#ifdef CONFIG_DARWIN
+if (len > 0) {
+/* Skip the IP header that OS X (unlike Linux) includes. */
+struct ip *inner_ip = mtod(m, struct ip *);
+int inner_hlen = inner_ip->ip_hl << 2;
+memmove(icp, (unsigned char *)icp + inner_hlen, len - inner_hlen);
+}
+#endif
 icp->icmp_id = id;
 
 m->m_data -= hlen;
-- 
2.17.0

[Qemu-devel] [PATCH v2] slirp: fix ICMP handling on macOS hosts

2018-07-28 Thread aoates--- via Qemu-devel

From: Andrew Oates 

On Linux, SOCK_DGRAM+IPPROTO_ICMP sockets give only the ICMP packet when
read from.  On macOS, however, the socket acts like a SOCK_RAW socket
and includes the IP header as well.

This change strips the extra IP header from the received packet on macOS
before sending it to the guest.

Signed-off-by: Andrew Oates 
---
v2: check validity of inner_hlen and update len appropriately

 slirp/ip_icmp.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/slirp/ip_icmp.c b/slirp/ip_icmp.c
index 0b667a429a..76c6d54b11 100644
--- a/slirp/ip_icmp.c
+++ b/slirp/ip_icmp.c
@@ -420,7 +420,21 @@ void icmp_receive(struct socket *so)
 icp = mtod(m, struct icmp *);
 
 id = icp->icmp_id;
-len = qemu_recv(so->s, icp, m->m_len, 0);
+len = qemu_recv(so->s, icp, M_ROOM(m), 0);
+#ifdef CONFIG_DARWIN
+if (len > 0) {
+/* Skip the IP header that OS X (unlike Linux) includes. */
+struct ip *inner_ip = mtod(m, struct ip *);
+int inner_hlen = inner_ip->ip_hl << 2;
+if (inner_hlen > len) {
+len = -1;
+errno = -EINVAL;
+} else {
+len -= inner_hlen;
+memmove(icp, (unsigned char *)icp + inner_hlen, len);
+}
+}
+#endif
 icp->icmp_id = id;
 
 m->m_data -= hlen;
-- 
2.17.0

[Qemu-devel] [PATCH 2/2] vdi: refine code for vdi_open

2018-07-29 Thread yuchenlin--- via Qemu-devel

From: yuchenlin 

When the condition of each if or else if is true,
the code flow will goto fail. Which means we can decouple
if else if chain to get some readability.

Signed-off-by: yuchenlin 
---
 block/vdi.c | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/block/vdi.c b/block/vdi.c
index 12f92e7891..28fc6210a7 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -405,35 +405,41 @@ static int vdi_open(BlockDriverState *bs, QDict *options, 
int flags,
")", header.signature);
 ret = -EINVAL;
 goto fail;
-} else if (header.version != VDI_VERSION_1_1) {
+}
+if (header.version != VDI_VERSION_1_1) {
 error_setg(errp, "unsupported VDI image (version %" PRIu32 ".%" PRIu32
")", header.version >> 16, header.version & 0x);
 ret = -ENOTSUP;
 goto fail;
-} else if (header.offset_bmap % SECTOR_SIZE != 0) {
+}
+if (header.offset_bmap % SECTOR_SIZE != 0) {
 /* We only support block maps which start on a sector boundary. */
 error_setg(errp, "unsupported VDI image (unaligned block map offset "
"0x%" PRIx32 ")", header.offset_bmap);
 ret = -ENOTSUP;
 goto fail;
-} else if (header.offset_data % SECTOR_SIZE != 0) {
+}
+if (header.offset_data % SECTOR_SIZE != 0) {
 /* We only support data blocks which start on a sector boundary. */
 error_setg(errp, "unsupported VDI image (unaligned data offset 0x%"
PRIx32 ")", header.offset_data);
 ret = -ENOTSUP;
 goto fail;
-} else if (header.sector_size != SECTOR_SIZE) {
+}
+if (header.sector_size != SECTOR_SIZE) {
 error_setg(errp, "unsupported VDI image (sector size %" PRIu32
" is not %u)", header.sector_size, SECTOR_SIZE);
 ret = -ENOTSUP;
 goto fail;
-} else if (header.block_size != DEFAULT_CLUSTER_SIZE) {
+}
+if (header.block_size != DEFAULT_CLUSTER_SIZE) {
 error_setg(errp, "unsupported VDI image (block size %" PRIu32
  " is not %" PRIu64 ")",
header.block_size, DEFAULT_CLUSTER_SIZE);
 ret = -ENOTSUP;
 goto fail;
-} else if (header.disk_size >
+}
+if (header.disk_size >
(uint64_t)header.blocks_in_image * header.block_size) {
 error_setg(errp, "unsupported VDI image (disk size %" PRIu64 ", "
"image bitmap has room for %" PRIu64 ")",
@@ -441,15 +447,18 @@ static int vdi_open(BlockDriverState *bs, QDict *options, 
int flags,
(uint64_t)header.blocks_in_image * header.block_size);
 ret = -ENOTSUP;
 goto fail;
-} else if (!qemu_uuid_is_null(&header.uuid_link)) {
+}
+if (!qemu_uuid_is_null(&header.uuid_link)) {
 error_setg(errp, "unsupported VDI image (non-NULL link UUID)");
 ret = -ENOTSUP;
 goto fail;
-} else if (!qemu_uuid_is_null(&header.uuid_parent)) {
+}
+if (!qemu_uuid_is_null(&header.uuid_parent)) {
 error_setg(errp, "unsupported VDI image (non-NULL parent UUID)");
 ret = -ENOTSUP;
 goto fail;
-} else if (header.blocks_in_image > VDI_BLOCKS_IN_IMAGE_MAX) {
+}
+if (header.blocks_in_image > VDI_BLOCKS_IN_IMAGE_MAX) {
 error_setg(errp, "unsupported VDI image "
  "(too many blocks %u, max is %u)",
   header.blocks_in_image, VDI_BLOCKS_IN_IMAGE_MAX);
-- 
2.17.0

[Qemu-devel] [PATCH 0/2] Refine some vdi code

2018-07-29 Thread yuchenlin--- via Qemu-devel

From: yuchenlin 

This series refine some code in vdi.c, includes:

* Remvoe CONFIG_VDI_WRITE because there is no reason to leave an always on
  and cannot configure option in the code-side.
* decouple if else if chain to get more readability.

Thanks,
yuchenlin

yuchenlin (2):
  vdi: remove CONFIG_VDI_WRITE
  vdi: refine code for vdi_open

 block/vdi.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

-- 
2.17.0

[Qemu-devel] [PATCH 1/2] vdi: remove CONFIG_VDI_WRITE

2018-07-29 Thread yuchenlin--- via Qemu-devel

From: yuchenlin 

The CONFIG_VDI_WRITE is here when the first time vdi is added.
But there is no reason to leave an always on and cannot configure option
in the code-side.

Signed-off-by: yuchenlin 
---
 block/vdi.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/block/vdi.c b/block/vdi.c
index 6555cffb88..12f92e7891 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -70,9 +70,6 @@
 /* Enable debug messages. */
 //~ #define CONFIG_VDI_DEBUG
 
-/* Support write operations on VDI images. */
-#define CONFIG_VDI_WRITE
-
 /* Support non-standard block (cluster) size. This is untested.
  * Maybe it will be needed for very large images.
  */
@@ -1016,9 +1013,7 @@ static BlockDriver bdrv_vdi = {
 .bdrv_make_empty = vdi_make_empty,
 
 .bdrv_co_preadv = vdi_co_preadv,
-#if defined(CONFIG_VDI_WRITE)
 .bdrv_co_pwritev= vdi_co_pwritev,
-#endif
 
 .bdrv_get_info = vdi_get_info,
 
-- 
2.17.0

Re: [Qemu-devel] [PATCH 0/2] Refine some vdi code

2018-07-30 Thread yuchenlin via Qemu-devel

Hi, Stefan

I agree that redundancy of If else may helps people to understand the code.

However, CONFIG_VDI_WRITE only contributes:

#if defined(CONFIG_VDI_WRITE)
.bdrv_co_pwritev = vdi_co_pwritev,
#endif

I think we don't need CONFIG_VDI_WRITE to document the code.
As its name implies, vdi_co_pwritev shows the code parts for vdi write support.


I appreciated your time and effort for reviews.

Regards,
yuchenlin


Stefan Weil  於 2018-07-30 15:13 寫道：
> Am 30.07.2018 um 04:46 schrieb yuchen...@synology.com: > From: yuchenlin 
>  > > This series refine some code in vdi.c, includes: 
> > > * Remvoe CONFIG_VDI_WRITE because there is no reason to leave an always 
> on > and cannot configure option in the code-side. > * decouple if else if 
> chain to get more readability. > > Thanks, > yuchenlin > > yuchenlin (2): > 
> vdi: remove CONFIG_VDI_WRITE > vdi: refine code for vdi_open > > block/vdi.c 
> | 32 ++-- > 1 file changed, 18 insertions(+), 14 
> deletions(-) Technically these changes are fine, but personally I prefer my 
> old code. If else is rendundant here, but redundancy helps humans to 
> understand the code. CONFIG_VDI_WRITE still has a similar function as it 
> documents which code parts are relevant for write support. Stefan

Re: [Qemu-devel] ivshmem Windows Driver

2017-10-16 Thread geoff--- via Qemu-devel

Hi Yan & Ladi.

I have written an initial implementation that supports just the shared
memory
mapping at this time. I plan to add events also but before I go further
I would

like some feedback if possible on what I have implemented thus far.

Please see:

https://github.com/gnif/kvm-guest-drivers-windows/commit/8655cf12fbdd77b991f96d97bc20f967b5907c12

Kind Regards,
Geoff

On 2017-10-15 23:29, ge...@hostfission.com wrote:

On 2017-10-15 23:24, Yan Vugenfirer wrote:

On 15 Oct 2017, at 15:21, ge...@hostfission.com wrote:

Hi Yan,

Thank you for the information. I am rather new to Windows Driver
development and learning as I go, so this may take some time, but
since the driver only needs to perform very basic functions I do not
see this as being too much of a challenge.

I think you can look into Windows virtio-balloon implementation as an
example of simple driver:
https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/Balloon

It relies on virtio library
(https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/VirtIO)
and it is WDF driver (MS framework that simplifies the drivers
development) that makes it very simple.

Thanks again, I already have a prototype driver working using WDF,
it's more learning the windows internals and how to best implement
things.

-Geoff

On 2017-10-15 22:14, Yan Vugenfirer wrote:

He Geoff,
The official virtio-win drivers upstream repository is here:
https://github.com/virtio-win/kvm-guest-drivers-windows
1. There is no ivshmem Windows Driver for now as far as I know
2. We are signing the drivers for community usage
https://fedoraproject.org/wiki/Windows_Virtio_Drivers from the same
repository.
The process will be: submit the code for review with pull request
(better use existing virtio library for virtio communication between
the guest and the host), pass internal tests and at the least being
able to pass MS HCK\HLK tests, later on the driver will be pulled
into

official build and release with rest of the drivers for community
usage.
3. We are happy to cooperate on adding new functionality to current
package of virtio drivers for Windows
4. As already mentioned:
https://github.com/virtio-win/kvm-guest-drivers-windows

Thanks a lot!
If you have more questions, please don’t hesitate to talk to me,
Ladi

or anyone else from Red Hat involved with virtio-win development.
Best regards,
Yan.
On 15 Oct 2017, at 12:32, geoff--- via Qemu-devel
wrote:

Hi All,
I am writing some code that needs to share a block of ram between a
Windows guest and Linux host. For this I am using the ivshmem
device and I have written a very primitive driver for windows that
allows a single application to request to memory map the pci bar
(shared memory) into the program's context using DeviceIoControl.
This is all working fine, but the next problem is I need the driver
to be signed. In it's current state I would not even suggest it be
signed as it was just hacked together to test my concept, but now I
know it's viable I would be willing to invest whatever time is
required to write a driver that would be acceptable for signing.
The ideal driver would be general purpose and could be leveraged
for any user mode application use, not just my specific case. It
would need to implement the IRQ/even features of ivshmem and
possibly even some kind of security to prevent unauthorized use by
rogue applications (shared secret configured on the chardev?).

I have several qustions:
1) Has someone done this? I can't find any reference to a windows
driver for this device anywhere.
2) If I was to pursue writing this driver, how would be the best
way to go about it so as to ensure that it is in a state that it
could be signed with the RedHat vendor key?

3) What is the likelihood of having such a driver signed?
4) Is there a preferred git host for such a driver?
Kind Regards
-Geoff

Re: [Qemu-devel] ivshmem Windows Driver

2017-10-17 Thread geoff--- via Qemu-devel

On 2017-10-18 16:31, Ladi Prosek wrote:

Hi Geoff,

On Mon, Oct 16, 2017 at 8:31 PM, wrote:

Hi Yan & Ladi.

I have written an initial implementation that supports just the shared
memory
mapping at this time. I plan to add events also but before I go
further I

would
like some feedback if possible on what I have implemented thus far.

Please see:

https://github.com/gnif/kvm-guest-drivers-windows/commit/8655cf12fbdd77b991f96d97bc20f967b5907c12

Thank you, looks good overall.

* Please don't use the 'vio' prefix for this driver. ivshmem is not a
VirtIO device (i.e. not using the VirtIO protocol). Also the test
program should live in a subdirectory, so maybe something like
/ivshmem and /ivshmem/test.

Noted, I will remove the prefix throughout and move the test
application.

* In VIOIVSHMEMEvtDevicePrepareHardware: I don't think that Windows
guarantees that resources are enumerated in BAR order. In VirtIO
drivers we read the PCI config space to identify the BAR index:
https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/VirtIO/VirtIOPCICommon.c#L353

The windows 'toaster' sample relies on the resource order, but as a
belt and braces approach I will update the code to use the same
approach.

* IOCTL codes on Windows have a structure to them:
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/defining-i-o-control-codes

Thanks, I will fix this.

* In VIOIVSHMEMEvtIoDeviceControl: The "only one mapping at a time is
allowed" test has a race. I think that simply making the IO queue
WdfIoQueueDispatchSequential instead of WdfIoQueueDispatchParallel
will fix it.

Good point, I will change this.

* According to MSDN, MmMapLockedPagesSpecifyCache(UserMode) should be
wrapped in try/except. Also, what happens if the file handle is
inherited by a child process? Can it unmap the mapping in parent's
address space? What if the parent exits? A possible solution is
discussed in this article:
http://www.osronline.com/article.cfm?article=39

Noted re try/except. As for a child inheriting it, the owner is tracked
by the WDFFILEOBJECT, which the child I believe will inherit also, which
would mean that the child would gain the ability to issue IOCTLs to the
mapping.

Thanks!
Ladi

No, thank you! I am grateful someone is willing to provide some feedback
on this.

I have been working on adding MSI interrupt support to the driver
also which is close to ready, just trying to figure out why the driver
fails to start with STATUS_DEVICE_POWER_FAILURE when I try to setup the
IRQs with WdfInterruptCreate.

Thanks again,
Geoff

Re: [Qemu-devel] ivshmem Windows Driver

2017-10-17 Thread geoff--- via Qemu-devel

On 2017-10-18 17:50, Ladi Prosek wrote:

On Wed, Oct 18, 2017 at 7:50 AM, wrote:

On 2017-10-18 16:31, Ladi Prosek wrote:

Hi Geoff,

On Mon, Oct 16, 2017 at 8:31 PM, wrote:

Hi Yan & Ladi.

I have written an initial implementation that supports just the
shared

memory
mapping at this time. I plan to add events also but before I go
further I

would
like some feedback if possible on what I have implemented thus far.

Please see:

https://github.com/gnif/kvm-guest-drivers-windows/commit/8655cf12fbdd77b991f96d97bc20f967b5907c12

Thank you, looks good overall.

Noted, I will remove the prefix throughout and move the test
application.

* In VIOIVSHMEMEvtDevicePrepareHardware: I don't think that Windows
guarantees that resources are enumerated in BAR order. In VirtIO
drivers we read the PCI config space to identify the BAR index:

https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/VirtIO/VirtIOPCICommon.c#L353

The windows 'toaster' sample relies on the resource order, but as a
belt and braces approach I will update the code to use the same
approach.

Interesting, thanks! If that's really the case then we can remove the
code from VirtioLib. I have cloned the latest Windows-driver-samples
but can't find this under general/toaster. Namely
ToasterEvtDevicePrepareHardware just prints some info about all
resources but does not do anything order-related. Can you point me to
the right code?

Sorry, my mistake, it wasn't the toaster code but the kmdf driver, it
assumes the BAR ordering to determine which is which.

https://github.com/Microsoft/Windows-driver-samples/blob/aa6e0b36eb932099fa4eb950a6f5e289a23b6d6e/general/pcidrv/kmdf/HW/nic_init.c#L649

* IOCTL codes on Windows have a structure to them:

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/defining-i-o-control-codes

Thanks, I will fix this.

Good point, I will change this.

Noted re try/except. As for a child inheriting it, the owner is
tracked
by the WDFFILEOBJECT, which the child I believe will inherit also,
which
would mean that the child would gain the ability to issue IOCTLs to
the

mapping.

Thanks!
Ladi

No, thank you! I am grateful someone is willing to provide some
feedback

on this.

IRQs with WdfInterruptCreate.

Thanks again,
Geoff

Re: [Qemu-devel] ivshmem Windows Driver

2017-10-18 Thread geoff--- via Qemu-devel


Hi Ladi & Yan,

I am pleased to present the completed driver for review, please see:

https://github.com/gnif/kvm-guest-drivers-windows

All issues previously mentioned have been addressed and all missing
functionality has been added.

Please note that this work has exposed a bug in the qemu ivshmem
virtual device itself, it seems that if the MSI interrupts are enabled
and the driver is unloaded twice an assertion is thrown due to what
looks to be a double free, crashing out qemu.

Once this driver has been finalized I will look into the cause of
this problem and see if I can correct it also.

Kind Regards,
Geoffrey McRae

Re: [Qemu-devel] ivshmem Windows Driver


On 2017-10-19 19:35, Ladi Prosek wrote:

On Wed, Oct 18, 2017 at 5:04 PM,   wrote:

Hi Ladi & Yan,

I am pleased to present the completed driver for review, please see:

https://github.com/gnif/kvm-guest-drivers-windows


Awesome!

Feel free to open pull request, it should be easier to comment on.


Great, I will do so after I have addressed the below. Thanks again.



* WoW considerations: It would be nice if the driver could detect that
the map request is coming from a 32-bit process and expect a different
layout of struct IVSHMEM_MMAP.


I did think of this but I am unsure as to how to detect this.



* It would be cleaner to use READ_REGISTER_* and WRITE_REGISTER_*
from/to IVSHMEMDeviceRegisters instead of plain memory accesses. Or at
the very least the accesses should be marked volatile.


I thought that mapping the IO space was enough for this since it is
mapped as non-cacheable. I can see the point of marking it volatile but
see no need to use the read/write register semantics. If this is what it
takes however I am happy to do so.



* In ivshmem.inf: ManufacturerName="Red Hat, Inc." instead of "RedHat"



No worries.


* Is any of the API used by the driver Win10-only? Just curious, it's
fine to build the driver only for Win10 for now even if it isn't.


I have not tried to build it on anything older then win 10 build 10586
as I have nothing older, but AFAIK it should build on windows 8.1 or
later just fine. This is more due to my lack of familiarity with Visual
Studio, give me gcc and vim any day :).



Thanks!


All issues previously mentioned have been addressed and all missing
functionality has been added.

Please note that this work has exposed a bug in the qemu ivshmem
virtual device itself, it seems that if the MSI interrupts are enabled
and the driver is unloaded twice an assertion is thrown due to what
looks to be a double free, crashing out qemu.

Once this driver has been finalized I will look into the cause of
this problem and see if I can correct it also.

Kind Regards,
Geoffrey McRae

Re: [Qemu-devel] ivshmem Windows Driver


On 2017-10-19 20:01, Ladi Prosek wrote:

On Thu, Oct 19, 2017 at 10:44 AM,   wrote:

On 2017-10-19 19:35, Ladi Prosek wrote:


On Wed, Oct 18, 2017 at 5:04 PM,   wrote:


Hi Ladi & Yan,

I am pleased to present the completed driver for review, please see:

https://github.com/gnif/kvm-guest-drivers-windows



Awesome!

Feel free to open pull request, it should be easier to comment on.



Great, I will do so after I have addressed the below. Thanks again.



* WoW considerations: It would be nice if the driver could detect 
that
the map request is coming from a 32-bit process and expect a 
different

layout of struct IVSHMEM_MMAP.



I did think of this but I am unsure as to how to detect this.


I don't think I ever used it but IoIs32bitProcess() looks promising.



* It would be cleaner to use READ_REGISTER_* and WRITE_REGISTER_*
from/to IVSHMEMDeviceRegisters instead of plain memory accesses. Or 
at

the very least the accesses should be marked volatile.



I thought that mapping the IO space was enough for this since it is
mapped as non-cacheable. I can see the point of marking it volatile 
but
see no need to use the read/write register semantics. If this is what 
it

takes however I am happy to do so.


Code like this raises eyebrows:

  deviceContext->devRegisters->doorbell |= (UINT32)in->vector |
(in->peerID << 16);

Many readers will probably be wondering what exactly the compiler is
allowed to do with this statement. May it end up ORing the lower and
upper word separately, for example?

  OR [word ptr addr], in->vector
  OR [word ptr addr + 2], in->peerID

And, by the way, is OR really what we want here?



After double checking this you are dead right, the register is 
documented

as write only. I will fix this.



* In ivshmem.inf: ManufacturerName="Red Hat, Inc." instead of 
"RedHat"




No worries.


* Is any of the API used by the driver Win10-only? Just curious, it's
fine to build the driver only for Win10 for now even if it isn't.



I have not tried to build it on anything older then win 10 build 10586
as I have nothing older, but AFAIK it should build on windows 8.1 or
later just fine. This is more due to my lack of familiarity with 
Visual

Studio, give me gcc and vim any day :).


Gotcha, no worries, other versions can be tested later.

Re: [Qemu-devel] ivshmem Windows Driver


On 2017-10-19 20:07, ge...@hostfission.com wrote:

On 2017-10-19 20:01, Ladi Prosek wrote:

On Thu, Oct 19, 2017 at 10:44 AM,   wrote:

On 2017-10-19 19:35, Ladi Prosek wrote:


On Wed, Oct 18, 2017 at 5:04 PM,   wrote:


Hi Ladi & Yan,

I am pleased to present the completed driver for review, please 
see:


https://github.com/gnif/kvm-guest-drivers-windows



Awesome!

Feel free to open pull request, it should be easier to comment on.



Great, I will do so after I have addressed the below. Thanks again.



I have created a PR, see:

https://github.com/virtio-win/kvm-guest-drivers-windows/pull/174



* WoW considerations: It would be nice if the driver could detect 
that
the map request is coming from a 32-bit process and expect a 
different

layout of struct IVSHMEM_MMAP.



I did think of this but I am unsure as to how to detect this.


I don't think I ever used it but IoIs32bitProcess() looks promising.




Obviously PVOID will be 32bit which will mess with the struct size and
offset of vectors but I am not aware of a solution to this. If you have
any suggestions on how to rectify this it would be very much 
appreciated.




* It would be cleaner to use READ_REGISTER_* and WRITE_REGISTER_*
from/to IVSHMEMDeviceRegisters instead of plain memory accesses. Or 
at

the very least the accesses should be marked volatile.



I thought that mapping the IO space was enough for this since it is
mapped as non-cacheable. I can see the point of marking it volatile 
but
see no need to use the read/write register semantics. If this is what 
it

takes however I am happy to do so.


Code like this raises eyebrows:

  deviceContext->devRegisters->doorbell |= (UINT32)in->vector |
(in->peerID << 16);

Many readers will probably be wondering what exactly the compiler is
allowed to do with this statement. May it end up ORing the lower and
upper word separately, for example?

  OR [word ptr addr], in->vector
  OR [word ptr addr + 2], in->peerID

And, by the way, is OR really what we want here?



After double checking this you are dead right, the register is 
documented

as write only. I will fix this.


Done.





* In ivshmem.inf: ManufacturerName="Red Hat, Inc." instead of 
"RedHat"




No worries.

* Is any of the API used by the driver Win10-only? Just curious, 
it's

fine to build the driver only for Win10 for now even if it isn't.



I have not tried to build it on anything older then win 10 build 
10586

as I have nothing older, but AFAIK it should build on windows 8.1 or
later just fine. This is more due to my lack of familiarity with 
Visual

Studio, give me gcc and vim any day :).


Gotcha, no worries, other versions can be tested later.

Re: [Qemu-devel] ivshmem Windows Driver


On 2017-10-19 20:51, Ladi Prosek wrote:

On Thu, Oct 19, 2017 at 11:41 AM,   wrote:

On 2017-10-19 20:07, ge...@hostfission.com wrote:


On 2017-10-19 20:01, Ladi Prosek wrote:


On Thu, Oct 19, 2017 at 10:44 AM,   wrote:


On 2017-10-19 19:35, Ladi Prosek wrote:



On Wed, Oct 18, 2017 at 5:04 PM,   wrote:



Hi Ladi & Yan,

I am pleased to present the completed driver for review, please 
see:


https://github.com/gnif/kvm-guest-drivers-windows




Awesome!

Feel free to open pull request, it should be easier to comment on.




Great, I will do so after I have addressed the below. Thanks again.



I have created a PR, see:

https://github.com/virtio-win/kvm-guest-drivers-windows/pull/174



* WoW considerations: It would be nice if the driver could detect 
that
the map request is coming from a 32-bit process and expect a 
different

layout of struct IVSHMEM_MMAP.




I did think of this but I am unsure as to how to detect this.



I don't think I ever used it but IoIs32bitProcess() looks promising.




Obviously PVOID will be 32bit which will mess with the struct size and
offset of vectors but I am not aware of a solution to this. If you 
have
any suggestions on how to rectify this it would be very much 
appreciated.


I was thinking something simple like:

#ifdef _WIN64
typedef struct IVSHMEM_MMAP_32
{
...
UINT32 ptr;
...
}
IVSHMEM_MMAP_32, *PIVSHMEM_MMAP_32;
#endif

in a private header. Then in the IOCTL handler call IoIs32bitProcess()
and if it returns true, expect IVSHMEM_MMAP_32 instead of
IVSHMEM_MMAP.


Ah that makes sense, thanks! This has been done.





* It would be cleaner to use READ_REGISTER_* and WRITE_REGISTER_*
from/to IVSHMEMDeviceRegisters instead of plain memory accesses. 
Or at

the very least the accesses should be marked volatile.




I thought that mapping the IO space was enough for this since it is
mapped as non-cacheable. I can see the point of marking it volatile 
but
see no need to use the read/write register semantics. If this is 
what it

takes however I am happy to do so.



Code like this raises eyebrows:

  deviceContext->devRegisters->doorbell |= (UINT32)in->vector |
(in->peerID << 16);

Many readers will probably be wondering what exactly the compiler is
allowed to do with this statement. May it end up ORing the lower and
upper word separately, for example?

  OR [word ptr addr], in->vector
  OR [word ptr addr + 2], in->peerID

And, by the way, is OR really what we want here?



After double checking this you are dead right, the register is 
documented

as write only. I will fix this.



Done.






* In ivshmem.inf: ManufacturerName="Red Hat, Inc." instead of 
"RedHat"




No worries.

* Is any of the API used by the driver Win10-only? Just curious, 
it's

fine to build the driver only for Win10 for now even if it isn't.




I have not tried to build it on anything older then win 10 build 
10586
as I have nothing older, but AFAIK it should build on windows 8.1 
or
later just fine. This is more due to my lack of familiarity with 
Visual

Studio, give me gcc and vim any day :).



Gotcha, no worries, other versions can be tested later.

[Qemu-devel] PCI Passthrough + AMD + NPT

2017-10-22 Thread geoff--- via Qemu-devel


Hi All,

I have started to dig into why ntp seems to slow down graphics 
performance on
AMD systems using PCI passthrough and figured I would report what I have 
so far
discovered. I have noted the primary point of failure seems to be 
specifically
with PhysX. This is why people only see a slow down in certain games, 
not

everything uses PhysX.

Using FluidMark[1] the problem is immediately obvious, showing extremely 
low
FPS on light/medium workloads with ntp enabled, and extreme fluididy and 
high

FPS with ntp disabled.

Switching nVidia to use CPU makes no difference to the performance when 
ntp
is enabled, which seems to indicate that PhysX is falling back to CPU 
due to

a failure of some kind to initialize.

With ntp turned off, and nVidia set to use the CPU for PhysX I see an
identical performance drop off in FluidMark as I see when ntp is 
enabled, this

would seem to confirm this suspicion.

Since other features such as APIC is only available if ntp is enabled, 
it

could be something down stream of ntp that is getting disabled as a
consequence of turning off ntp. It might be interesting to see if we can 
get
some diagnostics information out of PhysX to see what if any error or 
debugging

information it might provide when it falls back to CPU.

1: 
http://www.geeks3d.com/20130308/fluidmark-1-5-1-physx-benchmark-fluid-sph-simulation-opengl-download/


Kind Regards,
Geoffrey McRae

Re: [Qemu-devel] [Qemu-discuss] Accessing a shared folder

>Could you please try to replace the -virtfs option with these two options:
>
 >-fsdev local,id=shared,path=/home/mahmood/Downloads \
 >-device virtio-9p-pci,fsdev=shared,mount_tag=Downloads




Still get the same error!

mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 -hda 
centos7server.img -boot c  -usbdevice tablet -enable-kvm -device 
e1000,netdev=host_files -netdev user,net=10.0.2.0/24,id=host_files -fsdev 
local,id=shared,path=/home/mahmood/Downloads -device 
virtio-9p-pci,fsdev=shared,mount_tag=Downloads
qemu-system-x86_64: -device virtio-9p-pci,fsdev=shared,mount_tag=Downloads: 
Parameter 'driver' expects device type
mahmood@cluster:qemu-vm$




Regards,
Mahmood

Re: [Qemu-devel] [Qemu-discuss] Accessing a shared folder


The security_model=none also doesn't work and get the same error.

mahmood@cluster:qemu-vm$ qemu-system-x86_64 -version
QEMU emulator version 1.7.0, Copyright (c) 2003-2008 Fabrice Bellard


I know it is old but I think I installed this version three years ago due to 
the Rocks-6 version old libraries (which is based on Centos-6). I will try some 
newer versions to find which version is better.


One more question. How can I uninstall the qemu which is built from source? 
"make uninstall" in the source folder doesn't work.


Sorry for taking up your time.


Regards,
Mahmood

Re: [Qemu-devel] [Qemu-discuss] Accessing a shared folder

Hello again,I installed 2.5.0 quickly and it was pretty straight forward!

Here is the error message I get regarding the 'virtio-9p-pci'



mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 -hda 
centos7.img -boot c  -usbdevice tablet -enable-kvm -device 
e1000,netdev=host_files -netdev user,net=10.0.2.0/24,id=host_files -virtfs 
local,id=shared,path=/home/mahmood/Downloads,mount_tag=Downloads
warning: host doesn't support requested feature: 
CPUID.4001H:EAX.kvm_asyncpf [bit 4]
warning: host doesn't support requested feature: 
CPUID.4001H:EAX.kvm_asyncpf [bit 4]
qemu-system-x86_64: -virtfs 
local,id=shared,path=/home/mahmood/Downloads,mount_tag=Downloads: 
'virtio-9p-pci' is not a valid device model name
mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 -hda 
centos7.img -boot c  -usbdevice tablet -enable-kvm -device 
e1000,netdev=host_files -netdev user,net=10.0.2.0/24,id=host_files -fsdev 
local,id=shared,path=/home/mahmood/Downloads -device 
virtio-9p-pci,fsdev=shared,mount_tag=Downloads
warning: host doesn't support requested feature: 
CPUID.4001H:EAX.kvm_asyncpf [bit 4]
warning: host doesn't support requested feature: 
CPUID.4001H:EAX.kvm_asyncpf [bit 4]
qemu-system-x86_64: -device virtio-9p-pci,fsdev=shared,mount_tag=Downloads: 
'virtio-9p-pci' is not a valid device model name
mahmood@cluster:qemu-vm$ qemu-system-x86_64 -version
QEMU emulator version 2.5.0, Copyright (c) 2003-2008 Fabrice Bellard






I appreciate if you help. Thanks.


Regards,
Mahmood

Re: [Qemu-devel] [Qemu-discuss] Accessing a shared folder

OK. I reconfigured 2.9.0 with --enable-virtfs. Please note:
1- If I use -virtfs option, I get 
 qemu-option.c:547: opt_set: Assertion `opt->str' failed

2- If I use -fsdev and -device, then I *must* use security_model

3- If I use -fsdev and -device and security_model, then the guest boots 
normally.

I haven't tried to see if I am able to access the shared folder nor not. Do you 
have any note on the above items?


Regards,
Mahmood

Re: [Qemu-devel] [Qemu-discuss] Accessing a shared folder

2017-08-31 Thread Mahmood via Qemu-devel

Hello again,
For the command

    mount -t 9p -o trans=virtio Downloads /media/Downloads

inside the Centos-7 guest, I get this error

mount: unknown filesystem type '9p'

Any thought?

Regards,
Mahmood

Re: [Qemu-devel] [PATCH 1/3] ivshmem: Don't update non-existent MSI routes

2017-11-10 Thread geoff--- via Qemu-devel

Thanks Ladi, I had not yet had time to dig into these, this patch set 
resolves all issues I was aware of.


Tested-by: Geoffrey McRae 

On 2017-11-11 04:34, Ladi Prosek wrote:
As of commit 660c97eef6f8 ("ivshmem: use kvm irqfd for msi 
notifications"),

QEMU crashes with:

  kvm_irqchip_commit_routes: Assertion `ret == 0' failed.

if the ivshmem device is configured with more vectors than what the 
server

supports. This is caused by the ivshmem_vector_unmask() being called on
vectors that have not been initialized by ivshmem_add_kvm_msi_virq().

This commit fixes it by adding a simple check to the mask and unmask
callbacks.

Note that the opposite mismatch, if the server supplies more vectors 
than
what the device is configured for, is already handled and leads to 
output

like:

  Too many eventfd received, device has 1 vectors

Fixes: 660c97eef6f8 ("ivshmem: use kvm irqfd for msi notifications")
Signed-off-by: Ladi Prosek 
---
 hw/misc/ivshmem.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index a5a46827fe..6e46669744 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -317,6 +317,10 @@ static int ivshmem_vector_unmask(PCIDevice *dev,
unsigned vector,
 int ret;

 IVSHMEM_DPRINTF("vector unmask %p %d\n", dev, vector);
+if (!v->pdev) {
+error_report("ivshmem: vector %d route does not exist", 
vector);

+return -EINVAL;
+}

 ret = kvm_irqchip_update_msi_route(kvm_state, v->virq, msg, dev);
 if (ret < 0) {
@@ -331,12 +335,16 @@ static void ivshmem_vector_mask(PCIDevice *dev,
unsigned vector)
 {
 IVShmemState *s = IVSHMEM_COMMON(dev);
 EventNotifier *n = &s->peers[s->vm_id].eventfds[vector];
+MSIVector *v = &s->msi_vectors[vector];
 int ret;

 IVSHMEM_DPRINTF("vector mask %p %d\n", dev, vector);
+if (!v->pdev) {
+error_report("ivshmem: vector %d route does not exist", 
vector);

+return;
+}

-ret = kvm_irqchip_remove_irqfd_notifier_gsi(kvm_state, n,
-
s->msi_vectors[vector].virq);
+ret = kvm_irqchip_remove_irqfd_notifier_gsi(kvm_state, n, 
v->virq);

 if (ret != 0) {
 error_report("remove_irqfd_notifier_gsi failed");
 }

Re: [Qemu-devel] [PATCH 3/3] ivshmem: Improve MSI irqfd error handling

2017-11-13 Thread geoff--- via Qemu-devel


On 2017-11-14 04:27, Markus Armbruster wrote:

Ladi Prosek  writes:


Adds a rollback path to ivshmem_enable_irqfd() and fixes
ivshmem_disable_irqfd() to bail if irqfd has not been enabled.

Signed-off-by: Ladi Prosek 


Is this a theoretical bug, or can you trigger it?


It is reproducible, I can trigger it by simply unloading the windows 
driver and then attempting to re-load it.


-Geoff

[Qemu-devel] [Bug 1756080] [NEW] QEMU does not provide non-Linux kernels with ATAGS structure on ARM targets

2018-03-15 Thread barry.of.smith--- via Qemu-devel

Public bug reported:

This would be a useful feature. Many kernels, particularly hobbyist
kernels, have support for ATAGS.

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

Title:
  QEMU does not provide non-Linux kernels with ATAGS structure on ARM
  targets

Status in QEMU:
  New

Bug description:
  This would be a useful feature. Many kernels, particularly hobbyist
  kernels, have support for ATAGS.

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

[Qemu-devel] [Bug 1580459] Re: Windows (10?) guest freezes entire host on shutdown if using PCI passthrough

2017-12-18 Thread Benjamin via Qemu-devel

I've been experiencing something that sounds very similar to what has
been described in this issue post and want to see if you guys think it's
the same issue. For me from a cold boot everything is fine for a while
and I can restart my vm and such just fine. but after a long time or
stressful stuff mining/gaming if I shutdown my vm the host displays will
all go to sleep and the system locks up which I had been assuming is a
display driver crash. I can also sometimes trigger the exact same lockup
by calling lspci. once such a lockup has happened I have to hard reset.
where this gets even weirder is that after this happens I will get the
same lockup during the startup process around when xorg loads. when this
happens I either have to leave my computer alone for around 30 minutes
to an hour, or I can get it to boot by disabling iommu with iommu=off as
a kernel param, and then if I wait around 30 minutes to an hour I can
restart and it will boot fine again with iommu=pt (I get a kernel panic
if i don't use iommu=pt)

Hardware
Ryzen R5 1600
asrock ab350m pro4
32gb ram
Host gpu RX580
Guest gpu GTX1070

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

Title:
  Windows (10?) guest freezes entire host on shutdown if using PCI
  passthrough

Status in libvirt:
  New
Status in QEMU:
  New
Status in Arch Linux:
  New
Status in Debian:
  New
Status in Fedora:
  New

Bug description:
  Problem: after leaving a Windows VM that uses PCI passthrough (as we
  do for gaming graphics cards, sound cards, and in my case, a USB card)
  running for some amount of time between 1 and 2 hours (it's not
  consistent with exactly how long), and for any amount of time longer
  than that, shutting down that guest will, right as it finishes
  shutting down, freeze the host computer, making it require a hard
  reboot. Unbinding (or in the other user's case, unbinding and THEN
  binding) any PCI device in sysfs, even one that has nothing to do with
  the VM, also has the same effect as shutting down the VM (if the VM
  has been running long enough). So, it's probably an issue related to
  unbinding and binding PCI devices.

  There's a lot of info on this problem over at 
https://bbs.archlinux.org/viewtopic.php?id=206050
  Here's a better-organized list of main details:
  -at least 2 confirmed victims of this bug; 2 (including me) have provided 
lots of info in the link
  -I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific)
  -issue affects my Windows 10 guest and others' Windows guests, but not my 
Arch Linux guest (the others don't have non-Windows guests to test)
  -I'm using libvirt but the other user is not, so it's not an issue with 
libvirt
  -It seems to be version non-specific, too. I first noticed it at, or when 
testing versions still had the issue at (whichever version is lower), Linux 4.1 
and qemu 2.4.0. It still persists in all releases of both since, including the 
newest ones.
  -I can't track down exactly what package downgrade can fix it, as downgrading 
further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying 
changes such as downgrading ncurses, meaning I don't know whether it's a bug in 
QEMU, the Linux kernel, or some weird seemingly unrelated thing.
  -According to the other user, "graphics intensive gameplay (GTA V) can cause 
the crash to happen sooner," as soon as "15 minutes"
  -Also, "bringing up a second passthrough VM with separate hardware will cause 
the same crash," and "bringing up another VM before the two-hour mark will not 
result in a crash," further cementing that it's triggered by the un/binding of 
PCI devices.
  -This is NOT related to the very similar bug that can be worked around by not 
passing through the HDMI device or sound card. Even when we removed all traces 
of any sort of sound card from the VM, it still had the same behavior.

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

[Qemu-devel] [PATCH] vmdk: return ENOTSUP before offset overflow

2018-03-21 Thread yuchenlin--- via Qemu-devel

From: yuchenlin 

VMDK has a hard limitation of extent size, which is due to the size of grain
table entry is 32 bits. It means it can only point to a grain located at
offset = 2^32. To prevent offset overflow and record a useless offset
in grain table. We should return un-support here.

Signed-off-by: yuchenlin 
---
 block/vmdk.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/block/vmdk.c b/block/vmdk.c
index f94c49a9c0..d8fc961940 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -47,6 +47,9 @@
 #define VMDK4_FLAG_MARKER (1 << 17)
 #define VMDK4_GD_AT_END 0xULL
 
+/* 2TB */
+#define VMDK_EXTENT_SIZE_LIMIT (219902322)
+
 #define VMDK_GTE_ZEROED 0x1
 
 /* VMDK internal error codes */
@@ -1645,6 +1648,9 @@ static int vmdk_pwritev(BlockDriverState *bs, uint64_t 
offset,
 return ret;
 }
 if (m_data.valid) {
+if (cluster_offset > VMDK_EXTENT_SIZE_LIMIT) {
+return -ENOTSUP;
+}
 /* update L2 tables */
 if (vmdk_L2update(extent, &m_data,
   cluster_offset >> BDRV_SECTOR_BITS)
-- 
2.16.2

[Qemu-devel] [PATCH v2] vmdk: return ERROR when cluster sector is larger than vmdk limitation

2018-03-21 Thread yuchenlin--- via Qemu-devel

From: yuchenlin 

VMDK has a hard limitation of extent size, which is due to the size of grain
table entry is 32 bits. It means it can only point to a grain located at
offset = 2^32. To avoid writing the user data beyond limitation and record a 
useless offset
in grain table. We should return ERROR here.

Signed-off-by: yuchenlin 
---
v1->v2:
 - change commit message
 - check before allocating
 - should be >=
 - the unit is sector now

 thanks

 block/vmdk.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/block/vmdk.c b/block/vmdk.c
index f94c49a9c0..a1c21dbbba 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -47,6 +47,8 @@
 #define VMDK4_FLAG_MARKER (1 << 17)
 #define VMDK4_GD_AT_END 0xULL
 
+#define VMDK_EXTENT_MAX_SECTORS (4294967296)
+
 #define VMDK_GTE_ZEROED 0x1
 
 /* VMDK internal error codes */
@@ -1250,6 +1252,10 @@ static int get_cluster_offset(BlockDriverState *bs,
 return zeroed ? VMDK_ZEROED : VMDK_UNALLOC;
 }
 
+if (extent->next_cluster_sector >= VMDK_EXTENT_MAX_SECTORS) {
+return VMDK_ERROR;
+}
+
 cluster_sector = extent->next_cluster_sector;
 extent->next_cluster_sector += extent->cluster_sectors;
 
-- 
2.16.2

[Qemu-devel] [PATCH v3] vmdk: return ERROR when cluster sector is larger than vmdk limitation

2018-03-22 Thread yuchenlin--- via Qemu-devel

From: yuchenlin 

VMDK has a hard limitation of extent size, which is due to the size of grain
table entry is 32 bits. It means it can only point to a grain located at
offset = 2^32. To avoid writing the user data beyond limitation and record a 
useless offset
in grain table. We should return ERROR here.

Signed-off-by: yuchenlin 
---
v2->v3:
 - use (1ULL << 32) to clearly show the limitation of offset is 2^32.

 thanks

 block/vmdk.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/block/vmdk.c b/block/vmdk.c
index f94c49a9c0..84f8bbe480 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -47,6 +47,8 @@
 #define VMDK4_FLAG_MARKER (1 << 17)
 #define VMDK4_GD_AT_END 0xULL
 
+#define VMDK_EXTENT_MAX_SECTORS (1ULL << 32)
+
 #define VMDK_GTE_ZEROED 0x1
 
 /* VMDK internal error codes */
@@ -1250,6 +1252,10 @@ static int get_cluster_offset(BlockDriverState *bs,
 return zeroed ? VMDK_ZEROED : VMDK_UNALLOC;
 }
 
+if (extent->next_cluster_sector >= VMDK_EXTENT_MAX_SECTORS) {
+return VMDK_ERROR;
+}
+
 cluster_sector = extent->next_cluster_sector;
 extent->next_cluster_sector += extent->cluster_sectors;
 
-- 
2.16.2

Re: [Qemu-devel] [PATCH 01/13] target-openrisc: Write back result before FPE exception

2018-05-05 Thread BAndViG via Qemu-devel

I've read architecture manual again and found that my actual implementation 
differs from it.


How it should be (my updated view, thanks to your note).
The "Exception Processing" chapters stays than "EPCR (no delay slot)" should 
be "Address of next not executed instruction". And there is nothing about 
write-back discard.  It looks like it makes sense taking into account that 
IEEE-754 typically requires to return specially prepared value if an FPE 
occurs. As I remember correctly there are two approaches to compute the 
returned value. On of them is much simpler than another. For example, for 
overflow the value should be just +(-)Inf for simple approach but specially 
re-scaled for more complex one.


How it is implemented in CAPPUCCINO and MAROCCHINO pipes.
It look like till now I haven't been attentively enough. That's why my 
actual implementation follows "Synchronous/precise" approach that is 
write-back is discarded and "EPCR (no delay slot)" <= "Address of 
instruction that caused exception".


Currently I'm focused on implementation snoop-invalidation logic in 
MAROCCHINO and could not estimate when I could change FPE behavior. However, 
I'm voting to keep QEMU algorithms in consistent with actual HW- 
implementation. I remember that there is at list one QEMU to HW 
inconsistency that is implementation SPR_SR_DX. So Linux could run normally 
only in "SPR_SR_DX emulation" mode on HW SoCs. If we implement FPE 
processing in according to architecture manual now we increase number of 
QEMU-vs-HW inconsistencies.


PS. As I'm not a participant of QEMU developers mailing list, the letter 
could be rejected. Fill free to forward the answer there.


BR
Andrey Bacherov


-Исходное сообщение- 
From: Stafford Horne

Sent: Saturday, May 05, 2018 8:19 AM
To: Richard Henderson
Cc: qemu-devel@nongnu.org ; Richard Henderson ; band...@mail.ru
Subject: Re: [PATCH 01/13] target-openrisc: Write back result before FPE 
exception


On Thu, May 03, 2018 at 10:40:18PM -0700, Richard Henderson wrote:

From: Richard Henderson 

The architecture manual is unclear about this, but the or1ksim
does writeback before the exception.  This requires splitting
the helpers in half, with the exception raised by the second.


I dont really see a problem with this, ccing bandvig who did a lot of the 
fpu

hardware implementation in mor1kx.


Reviewed-by: Bastian Koppelmann 
Signed-off-by: Richard Henderson 


Acked-by: Stafford Horne 


---
 target/openrisc/helper.h |  25 +++--
 target/openrisc/fpu_helper.c | 250 
+--

 target/openrisc/translate.c  | 101 ++---
 3 files changed, 125 insertions(+), 251 deletions(-)

[Qemu-devel] [PATCH 1/2] ps2: Clear the queue on PS/2 mouse reset and obey device disable


This allows guest's to correctly reinitialize and identify the mouse
should the guest decide to re-scan or reset during mouse input events.

Signed-off-by: Geoffrey McRae 
---
 hw/input/ps2.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/input/ps2.c b/hw/input/ps2.c
index 06f5d2ac4a..6edf046820 100644
--- a/hw/input/ps2.c
+++ b/hw/input/ps2.c
@@ -673,6 +673,9 @@ static void ps2_mouse_sync(DeviceState *dev)
 {
 PS2MouseState *s = (PS2MouseState *)dev;

+if (!(s->mouse_status & MOUSE_STATUS_ENABLED))
+return;
+
 if (s->mouse_buttons) {
 qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER);
 }
@@ -776,6 +779,7 @@ void ps2_write_mouse(void *opaque, int val)
 s->mouse_resolution = 2;
 s->mouse_status = 0;
 s->mouse_type = 0;
+ps2_reset_queue(&s->common);
 ps2_queue(&s->common, AUX_ACK);
 ps2_queue(&s->common, 0xaa);
 ps2_queue(&s->common, s->mouse_type);
--
2.14.2

[Qemu-devel] [PATCH 2/2] ps2: Fix mouse stream corruption due to lost data


This fixes an issue by adding bounds checking to multi-byte packets
where the PS/2 mouse data stream may become corrupted due to data
being discarded when the PS/2 ringbuffer is full.

Interrupts for Multi-byte responses are postponed until the final
byte has been queued.

These changes fix a bug where windows guests drop the mouse device
entirely requring the guest to be restarted.

Signed-off-by: Geoffrey McRae 
---
 hw/input/pckbd.c |   6 +--
 hw/input/ps2.c   | 160 
+--

 2 files changed, 110 insertions(+), 56 deletions(-)

diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index f17f18e51b..004ea3466d 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -216,9 +216,9 @@ static uint64_t kbd_read_status(void *opaque, hwaddr 
addr,

 static void kbd_queue(KBDState *s, int b, int aux)
 {
 if (aux)
-ps2_queue(s->mouse, b);
+ps2_queue_raise(s->mouse, b);
 else
-ps2_queue(s->kbd, b);
+ps2_queue_raise(s->kbd, b);
 }

 static void outport_write(KBDState *s, uint32_t val)
diff --git a/hw/input/ps2.c b/hw/input/ps2.c
index 6edf046820..011290920f 100644
--- a/hw/input/ps2.c
+++ b/hw/input/ps2.c
@@ -192,12 +192,50 @@ void ps2_queue(PS2State *s, int b)
 {
 PS2Queue *q = &s->queue;

-if (q->count >= PS2_QUEUE_SIZE - 1)
+if (q->count == PS2_QUEUE_SIZE)
+{
+printf("Warning! PS2 Queue Overflow!\n");
 return;
+}
+
 q->data[q->wptr] = b;
 if (++q->wptr == PS2_QUEUE_SIZE)
 q->wptr = 0;
 q->count++;
+}
+
+void ps2_raise(PS2State *s)
+{
+s->update_irq(s->update_arg, 1);
+}
+
+void ps2_queue_raise(PS2State *s, int b)
+{
+ps2_queue(s, b);
+s->update_irq(s->update_arg, 1);
+}
+
+void ps2_queue_bytes(PS2State *s, const int length, ...)
+{
+PS2Queue *q = &s->queue;
+
+if (PS2_QUEUE_SIZE - q->count < length) {
+printf("Unable to send %d bytes, buffer full\n", length);
+return;
+}
+
+va_list args;
+va_start(args, length);
+
+for(int i = 0; i < length; ++i)
+{
+q->data[q->wptr] = va_arg(args, int);
+if (++q->wptr == PS2_QUEUE_SIZE)
+q->wptr = 0;
+q->count++;
+}
+
+va_end(args);
 s->update_irq(s->update_arg, 1);
 }

@@ -213,13 +251,13 @@ static void ps2_put_keycode(void *opaque, int 
keycode)

 if (keycode == 0xf0) {
 s->need_high_bit = true;
 } else if (s->need_high_bit) {
-ps2_queue(&s->common, translate_table[keycode] | 0x80);
+ps2_queue_raise(&s->common, translate_table[keycode] | 
0x80);

 s->need_high_bit = false;
 } else {
-ps2_queue(&s->common, translate_table[keycode]);
+ps2_queue_raise(&s->common, translate_table[keycode]);
 }
 } else {
-ps2_queue(&s->common, keycode);
+ps2_queue_raise(&s->common, keycode);
 }
 }

@@ -490,72 +528,80 @@ void ps2_write_keyboard(void *opaque, int val)
 case -1:
 switch(val) {
 case 0x00:
-ps2_queue(&s->common, KBD_REPLY_ACK);
+ps2_queue_raise(&s->common, KBD_REPLY_ACK);
 break;
 case 0x05:
-ps2_queue(&s->common, KBD_REPLY_RESEND);
+ps2_queue_raise(&s->common, KBD_REPLY_RESEND);
 break;
 case KBD_CMD_GET_ID:
-ps2_queue(&s->common, KBD_REPLY_ACK);
 /* We emulate a MF2 AT keyboard here */
-ps2_queue(&s->common, KBD_REPLY_ID);
 if (s->translate)
-ps2_queue(&s->common, 0x41);
+ps2_queue_bytes(&s->common, 3,
+KBD_REPLY_ACK,
+KBD_REPLY_ID,
+0x41);
 else
-ps2_queue(&s->common, 0x83);
+ps2_queue_bytes(&s->common, 3,
+KBD_REPLY_ACK,
+KBD_REPLY_ID,
+0x83);
 break;
 case KBD_CMD_ECHO:
-ps2_queue(&s->common, KBD_CMD_ECHO);
+ps2_queue_raise(&s->common, KBD_CMD_ECHO);
 break;
 case KBD_CMD_ENABLE:
 s->scan_enabled = 1;
-ps2_queue(&s->common, KBD_REPLY_ACK);
+ps2_queue_raise(&s->common, KBD_REPLY_ACK);
 break;
 case KBD_CMD_SCANCODE:
 case KBD_CMD_SET_LEDS:
 case KBD_CMD_SET_RATE:
 s->common.write_cmd = val;
-ps2_queue(&s->common, KBD_REPLY_ACK);
+ps2_queue_raise(&s->common, KBD_REPLY_ACK);
 break;
 case KBD_CMD_RESET_DISABLE:
 ps2_reset_keyboard(s);
 s->scan_enabled = 0;
-ps2_queue(&s->common, KBD_REPLY_ACK);
+ps2_queue_raise(&s->common, KBD_REPLY_ACK);
 break;
 case KBD_CMD_RESET_ENABLE:
 ps2_reset_keyboard(s);
 s->scan_enabled = 1;
-ps2_queue(&s->common, KBD_REPLY_ACK);
+ps2_queue_ra

Re: [Qemu-devel] [PATCH 1/2] ps2: Clear the queue on PS/2 mouse reset and obey device disable


On 2018-05-07 22:21, Gerd Hoffmann wrote:
On Mon, May 07, 2018 at 10:00:22PM +1000, geoff--- via Qemu-devel 
wrote:

This allows guest's to correctly reinitialize and identify the mouse
should the guest decide to re-scan or reset during mouse input events.

Signed-off-by: Geoffrey McRae 
---
 hw/input/ps2.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/input/ps2.c b/hw/input/ps2.c
index 06f5d2ac4a..6edf046820 100644
--- a/hw/input/ps2.c
+++ b/hw/input/ps2.c
@@ -673,6 +673,9 @@ static void ps2_mouse_sync(DeviceState *dev)
 {
 PS2MouseState *s = (PS2MouseState *)dev;

+if (!(s->mouse_status & MOUSE_STATUS_ENABLED))
+return;
+


Why this is needed?


To quote: 
https://wiki.osdev.org/%228042%22_PS/2_Controller#Detecting_PS.2F2_Device_Types


The device should respond to the "identify" command by sending a 
sequence of none, one or two identification bytes. However, if you just 
send the "identify" command you can't prevent the response from the 
"identify" command from being mixed up with keyboard/mouse data. To fix 
this problem, you need to send the "disable scanning" command first. 
Disabling scanning means that the device ignores the user (e.g. 
keyboards ignore keypresses, mice ignore mouse movement and button 
presses, etc) and won't send data to mess your device identification 
code up.





@@ -776,6 +779,7 @@ void ps2_write_mouse(void *opaque, int val)
 s->mouse_resolution = 2;
 s->mouse_status = 0;
 s->mouse_type = 0;
+ps2_reset_queue(&s->common);


Looks good.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 2/2] ps2: Fix mouse stream corruption due to lost data


On 2018-05-07 22:34, Gerd Hoffmann wrote:

diff --git a/hw/input/ps2.c b/hw/input/ps2.c
index 6edf046820..011290920f 100644
--- a/hw/input/ps2.c
+++ b/hw/input/ps2.c
@@ -192,12 +192,50 @@ void ps2_queue(PS2State *s, int b)
 {
 PS2Queue *q = &s->queue;

-if (q->count >= PS2_QUEUE_SIZE - 1)
+if (q->count == PS2_QUEUE_SIZE)
+{
+printf("Warning! PS2 Queue Overflow!\n");
 return;
+}


Leftover debug printf?


Correct :), I will remove it.




+void ps2_raise(PS2State *s)
+{
+s->update_irq(s->update_arg, 1);
+}
+
+void ps2_queue_raise(PS2State *s, int b)
+{
+ps2_queue(s, b);
+s->update_irq(s->update_arg, 1);
+}


I'd suggest to keep the ps2_queue() name.  Makes the patch much smaller
and easier to review.  Factor out the code to actually queue things to
a new ps2_queue_noirq() function.


+void ps2_queue_bytes(PS2State *s, const int length, ...)


Ack.



I'd prefer to not use vaargs here as gcc can't check the arguments 
then.

Suggest to just have ps2_queue_{2,3,4}() helpers instead to queue
multibyte messages.


Ack.



cheers,
  Gerd


Thanks,
  Geoff

Re: [Qemu-devel] [PATCH 1/2] ps2: Clear the queue on PS/2 mouse reset and obey device disable