Re: [Qemu-devel] [RFC PATCH] hw/arm/virt: use variable size of flash device to save memory

2019-03-25 Thread Zheng Xiang 
Hi Peter,

Thanks for your reply!

On 2019/3/25 21:11, Peter Maydell wrote:
> On Mon, 25 Mar 2019 at 12:53, Xiang Zheng  wrote:
>>
>> Currently we fill the VIRT_FLASH space with two 64MB NOR images when
>> using persistent UEFI variables on QEMU. Actually we only use a very
>> small part of the memory while the rest significant large part of
>> memory is wasted.
>>
>> This patch creates and maps a variable size of flash device instead of
>> a mandatory 64MB one to save memory.
>>
>> Signed-off-by: Xiang Zheng 
>> ---
>>
>> This patch might be insufficient since it also needs to modify the flash size
>> in ACPI and DTB.
>>
>> BTW, I don't understand why it requires the two NOR images to be exactly 64MB
>> in size when using -pflash.
> 
> I don't think we should do this. The board should in general
> create the same hardware visible to the guest, not change
> it based on subtle things like the size of the image files.
> 
> The reason why the flash images must be 64MB in size
> when using -pflash is that they are the backing store
> for a writable device. Suppose you have 1MB of data in your
> backing image that you pass to QEMU and then the guest writes
> to the last block of the flash device. The new data
> written by the guest to the end of the device has to be
> stored somewhere, so the file has to be large enough
> to cover the whole of the flash area.
> 

Is there any way to support config or limit the size that both
guest and QEMU are visible?

The original QEMU_EFI.fd has only 2M, but we need to stuff it
to 64M with 62M unused data. It will consume a large amount of
memory when running multiple VM simultaneously.


-- 

Thanks,
Xiang

Re: [Qemu-devel] [PATCH] scsi-cd: Fix crash after remote cdrom detached

2019-02-24 Thread Zheng Xiang 
Ping?

On 2019/2/15 11:17, Zheng Xiang wrote:
> Hi Paolo,
> 
> On 2019/2/15 2:07, Paolo Bonzini wrote:
>> On 14/02/19 13:27, Xiang Zheng wrote:
>>> There is a small window between the twice blk_is_available in
>>> scsi_disk_emulate_command which would cause crash due to the later
>>> assertion if the remote cdrom is detached in this window.
>>>
>>> So this patch replaces assertions with return to avoid qemu crash.
>>>
>>> Signed-off-by: Xiang Zheng 
>>> ---
>>> The qemu error log shows:
>>>
>>> qemu-system-aarch64: /home/qemu/hw/scsi/scsi-disk.c:1896: 
>>> scsi_disk_emulate_command: Assertion `blk_is_available(s->qdev.conf.blk)' 
>>> failed.
>>> 2019-02-15 04:35:18.592: shutting down, reason=crashed
>>
>> Is this with virtio-scsi-dataplane?
>>
> 
> No, the QEMU commandline about scsi is bellow:
>   -device virtio-scsi-pci,id=scsi0,bus=pci.4,addr=0x0 \
>   -drive 
> file=/mnt/zhengxiang/guestos.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none,aio=native
>  \
>   -device 
> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1
>  \
>   -drive 
> file=/home/tmp.iso,format=raw,if=none,id=drive-scsi0-0-0-1,readonly=on,cache=none,aio=threads
>  \
>   -device 
> scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1
> 
> This problem can be reproduced by detaching and attaching remote cdrom 
> repeatly.
> 
-- 

Thanks,
Xiang

Re: [Qemu-devel] [PATCH] scsi-cd: Fix crash after remote cdrom detached

2019-02-14 Thread Zheng Xiang 
Hi Paolo,

On 2019/2/15 2:07, Paolo Bonzini wrote:
> On 14/02/19 13:27, Xiang Zheng wrote:
>> There is a small window between the twice blk_is_available in
>> scsi_disk_emulate_command which would cause crash due to the later
>> assertion if the remote cdrom is detached in this window.
>>
>> So this patch replaces assertions with return to avoid qemu crash.
>>
>> Signed-off-by: Xiang Zheng 
>> ---
>> The qemu error log shows:
>>
>> qemu-system-aarch64: /home/qemu/hw/scsi/scsi-disk.c:1896: 
>> scsi_disk_emulate_command: Assertion `blk_is_available(s->qdev.conf.blk)' 
>> failed.
>> 2019-02-15 04:35:18.592: shutting down, reason=crashed
> 
> Is this with virtio-scsi-dataplane?
> 

No, the QEMU commandline about scsi is bellow:
-device virtio-scsi-pci,id=scsi0,bus=pci.4,addr=0x0 \
-drive 
file=/mnt/zhengxiang/guestos.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none,aio=native
 \
-device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1
 \
-drive 
file=/home/tmp.iso,format=raw,if=none,id=drive-scsi0-0-0-1,readonly=on,cache=none,aio=threads
 \
-device 
scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1

This problem can be reproduced by detaching and attaching remote cdrom repeatly.

-- 

Thanks,
Xiang

Re: [Qemu-devel] [PATCH] pcie: set link state inactive/active after hot unplug/plug

2018-12-02 Thread Zheng Xiang 
On 2018/12/3 11:38, Zheng Xiang wrote:
> When VM boots from the latest version of linux kernel, after
> hot-unpluging virtio-blk disks which are hotplugged into
> pcie-root-port, the VM's dmesg log shows:
> 
> [  151.046242] pciehp :00:05.0:pcie004: pending interrupts 0x0001 from 
> Slot Status
> [  151.046365] pciehp :00:05.0:pcie004: Slot(0-3): Attention button 
> pressed
> [  151.046369] pciehp :00:05.0:pcie004: Slot(0-3): Powering off due to 
> button press
> [  151.046420] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from 
> Slot Status
> [  151.046425] pciehp :00:05.0:pcie004: pciehp_green_led_blink: SLOTCTRL 
> a8 write cmd 200
> [  151.046464] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from 
> Slot Status
> [  151.046468] pciehp :00:05.0:pcie004: pciehp_set_attention_status: 
> SLOTCTRL a8 write cmd c0
> [  156.163421] pciehp :00:05.0:pcie004: pciehp_get_power_status: SLOTCTRL 
> a8 value read 2f1
> [  156.163427] pciehp :00:05.0:pcie004: pciehp_unconfigure_device: 
> domain:bus:dev = :06:00
> [  156.198736] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from 
> Slot Status
> [  156.198772] pciehp :00:05.0:pcie004: pciehp_power_off_slot: SLOTCTRL 
> a8 write cmd 400
> [  157.224124] pciehp :00:05.0:pcie004: pending interrupts 0x0018 from 
> Slot Status
> [  157.224194] pciehp :00:05.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 
> write cmd 300
> [  157.224220] pciehp :00:05.0:pcie004: pciehp_check_link_active: 
> lnk_status = 2011
> [  157.224223] pciehp :00:05.0:pcie004: Slot(0-3): Link Up
> [  157.224233] pciehp :00:05.0:pcie004: pciehp_get_power_status: SLOTCTRL 
> a8 value read 7f1
> [  157.224281] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from 
> Slot Status
> [  157.224285] pciehp :00:05.0:pcie004: pciehp_power_on_slot: SLOTCTRL a8 
> write cmd 0
> [  157.224300] pciehp :00:05.0:pcie004: __pciehp_link_set: lnk_ctrl = 0
> [  157.224336] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from 
> Slot Status
> [  157.224339] pciehp :00:05.0:pcie004: pciehp_green_led_blink: SLOTCTRL 
> a8 write cmd 200
> [  159.739294] pci :06:00.0 id reading try 50 times with interval 20 ms 
> to get 
> [  159.739315] pciehp :00:05.0:pcie004: pciehp_check_link_status: 
> lnk_status = 2011
> [  159.739318] pciehp :00:05.0:pcie004: Failed to check link status
> [  159.739371] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from 
> Slot Status
> [  159.739394] pciehp :00:05.0:pcie004: pciehp_power_off_slot: SLOTCTRL 
> a8 write cmd 400
> [  160.771426] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from 
> Slot Status
> [  160.771452] pciehp :00:05.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 
> write cmd 300
> [  160.771495] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from 
> Slot Status
> [  160.771499] pciehp :00:05.0:pcie004: pciehp_set_attention_status: 
> SLOTCTRL a8 write cmd 40
> [  160.771535] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from 
> Slot Status
> [  160.771539] pciehp :00:05.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 
> write cmd 300
> 
> After analyzing the log information, it seems that qemu doesn't
> change the Link Status from active to inactive after hot-unplug.
> This results in the abnormal log after the linux kernel commit
> d331710ea78fea merged.
> 
> Furthermore, If I hotplug the same virtio-blk disk after hot-unplug,
> the virtio-blk would turn on and then back off.
> 
> So this patch set the Link Status inactive after hot-unplug and
> active after hot-plug.
> 
> Signed-off-by: Zheng Xiang 
> Signed-off-by: Zheng Xiang 
Sorry, this signed off email should be xiang.zh...@linaro.org.

> Cc: Wang Haibin 
> ---
>  hw/pci/pcie.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> index 6c91bd4..66b73b8 100644
> --- a/hw/pci/pcie.c
> +++ b/hw/pci/pcie.c
> @@ -345,6 +345,10 @@ void pcie_cap_slot_hotplug_cb(HotplugHandler 
> *hotplug_dev, DeviceState *dev,
>  if (!dev->hotplugged) {
>  pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
> PCI_EXP_SLTSTA_PDS);
> +if (pci_dev->cap_present & QEMU_PCIE_LNKSTA_DLLLA) {
> +pci_word_test_and_set_mask(exp_cap + PCI_EXP_LNKSTA,
> +   PCI_EXP_LNKSTA_DLLLA);
> +}
>  return;
>  }
>  
> @@ -355,6 +359,10 @@ void pcie_cap_slot_hotplug_cb(HotplugHandler 
> *hotplug_dev, DeviceState *dev,
>  if (pci_get_function_0(pci_dev)) {
>  pci_word_test_and_set_mask(exp

[Qemu-devel] [PATCH] pcie: set link state inactive/active after hot unplug/plug

2018-12-02 Thread Zheng Xiang 
When VM boots from the latest version of linux kernel, after
hot-unpluging virtio-blk disks which are hotplugged into
pcie-root-port, the VM's dmesg log shows:

[  151.046242] pciehp :00:05.0:pcie004: pending interrupts 0x0001 from Slot 
Status
[  151.046365] pciehp :00:05.0:pcie004: Slot(0-3): Attention button pressed
[  151.046369] pciehp :00:05.0:pcie004: Slot(0-3): Powering off due to 
button press
[  151.046420] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  151.046425] pciehp :00:05.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 
write cmd 200
[  151.046464] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  151.046468] pciehp :00:05.0:pcie004: pciehp_set_attention_status: 
SLOTCTRL a8 write cmd c0
[  156.163421] pciehp :00:05.0:pcie004: pciehp_get_power_status: SLOTCTRL 
a8 value read 2f1
[  156.163427] pciehp :00:05.0:pcie004: pciehp_unconfigure_device: 
domain:bus:dev = :06:00
[  156.198736] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  156.198772] pciehp :00:05.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 
write cmd 400
[  157.224124] pciehp :00:05.0:pcie004: pending interrupts 0x0018 from Slot 
Status
[  157.224194] pciehp :00:05.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 
write cmd 300
[  157.224220] pciehp :00:05.0:pcie004: pciehp_check_link_active: 
lnk_status = 2011
[  157.224223] pciehp :00:05.0:pcie004: Slot(0-3): Link Up
[  157.224233] pciehp :00:05.0:pcie004: pciehp_get_power_status: SLOTCTRL 
a8 value read 7f1
[  157.224281] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  157.224285] pciehp :00:05.0:pcie004: pciehp_power_on_slot: SLOTCTRL a8 
write cmd 0
[  157.224300] pciehp :00:05.0:pcie004: __pciehp_link_set: lnk_ctrl = 0
[  157.224336] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  157.224339] pciehp :00:05.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 
write cmd 200
[  159.739294] pci :06:00.0 id reading try 50 times with interval 20 ms to 
get 
[  159.739315] pciehp :00:05.0:pcie004: pciehp_check_link_status: 
lnk_status = 2011
[  159.739318] pciehp :00:05.0:pcie004: Failed to check link status
[  159.739371] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  159.739394] pciehp :00:05.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 
write cmd 400
[  160.771426] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  160.771452] pciehp :00:05.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 
write cmd 300
[  160.771495] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  160.771499] pciehp :00:05.0:pcie004: pciehp_set_attention_status: 
SLOTCTRL a8 write cmd 40
[  160.771535] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  160.771539] pciehp :00:05.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 
write cmd 300

After analyzing the log information, it seems that qemu doesn't
change the Link Status from active to inactive after hot-unplug.
This results in the abnormal log after the linux kernel commit
d331710ea78fea merged.

Furthermore, If I hotplug the same virtio-blk disk after hot-unplug,
the virtio-blk would turn on and then back off.

So this patch set the Link Status inactive after hot-unplug and
active after hot-plug.

Signed-off-by: Zheng Xiang 
Signed-off-by: Zheng Xiang 
Cc: Wang Haibin 
---
 hw/pci/pcie.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 6c91bd4..66b73b8 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -345,6 +345,10 @@ void pcie_cap_slot_hotplug_cb(HotplugHandler *hotplug_dev, 
DeviceState *dev,
 if (!dev->hotplugged) {
 pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
PCI_EXP_SLTSTA_PDS);
+if (pci_dev->cap_present & QEMU_PCIE_LNKSTA_DLLLA) {
+pci_word_test_and_set_mask(exp_cap + PCI_EXP_LNKSTA,
+   PCI_EXP_LNKSTA_DLLLA);
+}
 return;
 }
 
@@ -355,6 +359,10 @@ void pcie_cap_slot_hotplug_cb(HotplugHandler *hotplug_dev, 
DeviceState *dev,
 if (pci_get_function_0(pci_dev)) {
 pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
PCI_EXP_SLTSTA_PDS);
+if (pci_dev->cap_present & QEMU_PCIE_LNKSTA_DLLLA) {
+pci_word_test_and_set_mask(exp_cap + PCI_EXP_LNKSTA,
+   PCI_EXP_LNKSTA_DLLLA);
+}
 pcie_cap_slot_event(PCI_DEVICE(hotplug_dev),
 PCI_EXP_HP_EV_PDC | PCI_EXP_HP_EV_ABP);
 }
@@ -531,6 +539,10 @@ void pcie_cap_slot_write_config(PCIDevice *dev,
 
 pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
  PCI_EXP_SLTSTA_PDS);
+if

[Qemu-devel] [PATCH] pcie: set link state inactive/active after hot unplug/plug

2018-12-02 Thread Zheng Xiang 
When VM boots from the latest version of linux kernel, after
hot-unpluging virtio-blk disks which are hotplugged into
pcie-root-port, the VM's dmesg log shows:

[  151.046242] pciehp :00:05.0:pcie004: pending interrupts 0x0001 from Slot 
Status
[  151.046365] pciehp :00:05.0:pcie004: Slot(0-3): Attention button pressed
[  151.046369] pciehp :00:05.0:pcie004: Slot(0-3): Powering off due to 
button press
[  151.046420] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  151.046425] pciehp :00:05.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 
write cmd 200
[  151.046464] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  151.046468] pciehp :00:05.0:pcie004: pciehp_set_attention_status: 
SLOTCTRL a8 write cmd c0
[  156.163421] pciehp :00:05.0:pcie004: pciehp_get_power_status: SLOTCTRL 
a8 value read 2f1
[  156.163427] pciehp :00:05.0:pcie004: pciehp_unconfigure_device: 
domain:bus:dev = :06:00
[  156.198736] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  156.198772] pciehp :00:05.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 
write cmd 400
[  157.224124] pciehp :00:05.0:pcie004: pending interrupts 0x0018 from Slot 
Status
[  157.224194] pciehp :00:05.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 
write cmd 300
[  157.224220] pciehp :00:05.0:pcie004: pciehp_check_link_active: 
lnk_status = 2011
[  157.224223] pciehp :00:05.0:pcie004: Slot(0-3): Link Up
[  157.224233] pciehp :00:05.0:pcie004: pciehp_get_power_status: SLOTCTRL 
a8 value read 7f1
[  157.224281] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  157.224285] pciehp :00:05.0:pcie004: pciehp_power_on_slot: SLOTCTRL a8 
write cmd 0
[  157.224300] pciehp :00:05.0:pcie004: __pciehp_link_set: lnk_ctrl = 0
[  157.224336] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  157.224339] pciehp :00:05.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 
write cmd 200
[  159.739294] pci :06:00.0 id reading try 50 times with interval 20 ms to 
get 
[  159.739315] pciehp :00:05.0:pcie004: pciehp_check_link_status: 
lnk_status = 2011
[  159.739318] pciehp :00:05.0:pcie004: Failed to check link status
[  159.739371] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  159.739394] pciehp :00:05.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 
write cmd 400
[  160.771426] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  160.771452] pciehp :00:05.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 
write cmd 300
[  160.771495] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  160.771499] pciehp :00:05.0:pcie004: pciehp_set_attention_status: 
SLOTCTRL a8 write cmd 40
[  160.771535] pciehp :00:05.0:pcie004: pending interrupts 0x0010 from Slot 
Status
[  160.771539] pciehp :00:05.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 
write cmd 300

After analyzing the log information, it seems that qemu doesn't
change the Link Status from active to inactive after hot-unplug.
This results in the abnormal log after the linux kernel commit
d331710ea78fea merged.

Furthermore, If I hotplug the same virtio-blk disk after hot-unplug,
the virtio-blk would turn on and then back off.

So this patch set the Link Status inactive after hot-unplug and
active after hot-plug.

Signed-off-by: Zheng Xiang 
Signed-off-by: Zheng Xiang 
Cc: Wang Haibin 
---
 hw/pci/pcie.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 6c91bd4..66b73b8 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -345,6 +345,10 @@ void pcie_cap_slot_hotplug_cb(HotplugHandler *hotplug_dev, 
DeviceState *dev,
 if (!dev->hotplugged) {
 pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
PCI_EXP_SLTSTA_PDS);
+if (pci_dev->cap_present & QEMU_PCIE_LNKSTA_DLLLA) {
+pci_word_test_and_set_mask(exp_cap + PCI_EXP_LNKSTA,
+   PCI_EXP_LNKSTA_DLLLA);
+}
 return;
 }
 
@@ -355,6 +359,10 @@ void pcie_cap_slot_hotplug_cb(HotplugHandler *hotplug_dev, 
DeviceState *dev,
 if (pci_get_function_0(pci_dev)) {
 pci_word_test_and_set_mask(exp_cap + PCI_EXP_SLTSTA,
PCI_EXP_SLTSTA_PDS);
+if (pci_dev->cap_present & QEMU_PCIE_LNKSTA_DLLLA) {
+pci_word_test_and_set_mask(exp_cap + PCI_EXP_LNKSTA,
+   PCI_EXP_LNKSTA_DLLLA);
+}
 pcie_cap_slot_event(PCI_DEVICE(hotplug_dev),
 PCI_EXP_HP_EV_PDC | PCI_EXP_HP_EV_ABP);
 }
@@ -531,6 +539,10 @@ void pcie_cap_slot_write_config(PCIDevice *dev,
 
 pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
  PCI_EXP_SLTSTA_PDS);
+if

[Qemu-devel] [PATCH] target-arm: fix a segmentation fault due to illegal memory access

2018-06-19 Thread Zheng Xiang 
From: Zheng Xiang 

The elements of kvm_devices_head list are freed in kvm_arm_machine_init_done(),
but we still access these illegal memory in kvm_arm_devlistener_del().

This will cause segment fault when booting guest with MALLOC_PERTURB_=1.

Signed-off-by: Zheng Xiang 
---
 target/arm/kvm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 98f5006..5bf41e1 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -256,6 +256,7 @@ static void kvm_arm_machine_init_done(Notifier *notifier, 
void *data)
 kvm_arm_set_device_addr(kd);
 }
 memory_region_unref(kd->mr);
+QSLIST_REMOVE_HEAD(_devices_head, entries);
 g_free(kd);
 }
 memory_listener_unregister();
-- 
1.8.3.1

[Qemu-devel] [PATCH] vhost: fix corrupting GPA 0 when using uninitialized queues

2018-01-12 Thread Zheng Xiang 
When guest driver only setup part of queues declared in QEMU, it
would corrupt guest's physical address 0 when using uninitialized
queues in vhost_virtqueue_start.

In AARCH64 virtual machines, the address of system memory starts at
0x4000 and the address of rom starts at 0. So, when using qemu
with vhost-scsi, it will fail with below error:
qemu-kvm: Error start vhost dev
qemu-kvm: unable to start vhost-scsi: Cannot allocate memory

This patch fix this issue by skipping calling vhost_virtqueue_start
for uninitialized queues.

Cc: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Zheng Xiang <zhengxia...@huawei.com>
---
 hw/virtio/vhost.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index e4290ce..ac79ffd 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -1532,6 +1532,8 @@ int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice 
*vdev)
 goto fail_mem;
 }
 for (i = 0; i < hdev->nvqs; ++i) {
+if (virtio_queue_get_desc_addr(vdev, hdev->vq_index + i) == 0) 
+continue;
 r = vhost_virtqueue_start(hdev,
   vdev,
   hdev->vqs + i,
-- 
1.8.3.1