Re: [Qemu-discuss] Is locking option available now?

[Fam Zheng]

- Original Message -
> I create backing file with 'locking=off', but it seems the locking is
> enabled:
> On *qemu-2.10*
> # qemu-img create -b 'json:{"file": {"driver": "file", "filename":
> "/var/lib/libvirt/images/V.qcow2", "*locking*": "*off*"}}'
> /var/lib/libvirt/images/a.qcow2 -f qcow2
> Formatting '/var/lib/libvirt/images/a.qcow2', fmt=qcow2 size=8589934592
> backing_file=json:{"file": {"driver": "file",, "filename":
> "/var/lib/libvirt/images/V.qcow2",, "locking": "off"}} cluster_size=65536
> lazy_refcounts=off refcount_bits=16
> 
> Then checking if locking works:
> # qemu-kvm /var/lib/libvirt/images/a.qcow2
> 
> VNC server running on ::1:5900
> 
> # qemu-img info /var/lib/libvirt/images/a.qcow2
> qemu-img: Could not open '/var/lib/libvirt/images/a.qcow2': Failed to get
> shared "write" lock
> Is another process using the image?
> 
> It looks "*locking=off*" not worked. So is this option available now? In
> which version this feature will be supported?

This is a run time option, not creation time. So if you don't want locking, 
always provide locking=off when invoking qemu, qemu-img, etc., not just when 
creating.

[Qemu-discuss] PCI passthrough error with IGB multiport ethernet

[Jan Schermer]

Hi,
I’m trying to passthrough two dual-port cards to a guest.
It seems to work fine until I actually the cards, then I get:

[  306.667890] pcieport :00:03.0: AER: Multiple Uncorrected (Fatal) error 
received: id=
[  306.667904] vfio-pci :03:00.0: PCIe Bus Error: severity=Uncorrected 
(Fatal), type=Unaccessible, id=0300(Unregistered Agent ID)
[  306.667998] vfio-pci :03:00.1: PCIe Bus Error: severity=Uncorrected 
(Fatal), type=Unaccessible, id=0301(Unregistered Agent ID)
[  306.668102] vfio-pci :03:00.0: broadcast error_detected message
[  307.710345] pcieport :00:03.0: Root Port link has been reset
[  307.710352] vfio-pci :03:00.0: broadcast mmio_enabled message
[  307.710355] vfio-pci :03:00.0: broadcast resume message
[  307.710357] vfio-pci :03:00.0: AER: Device recovery successful
[  307.710360] vfio-pci :03:00.1: broadcast error_detected message
[  308.734333] pcieport :00:03.0: Root Port link has been reset
[  308.734338] vfio-pci :03:00.1: broadcast mmio_enabled message
[  308.734340] vfio-pci :03:00.1: broadcast resume message
[  308.734342] vfio-pci :03:00.1: AER: Device recovery successful

I swapped one card already in case it was faulty, now I got the same error on 
the second one (above).

This is the configuration:

   
  

  
  


  

  
  


  

  
  


  

  
  


Am I passing those devices correctly or can I somehow pass the “whole” device? 

When I kill the guest the host sometimes recovers and sees both cards (all 4 
ports), sometimes it doesn’t.

I found this 
http://events.linuxfoundation.org/sites/events/files/slides/AER%20functionality%20of%20pass-through%20PCI-e%20device%20in%20Qemu.pdf
 

 which didn’t exactly make me happy, but I’m already using a somewhat similiar 
setup on a different machine where it just works. (there I’m passing one 
function to VM1 and another to VM2, which I’m not sure now should even work? 
:)).

I tried options vfio-pci disable_idle_d3=1 nointxmask=1 but that didn’t help.

Any ideas how to get it working? Is this a HW issue? A platform problem? 

Hypervisor is Ubuntu 17.10, guest is Ubuntu 17.10 as well (kernel 4.13.0, qemu 
2.10)

Thanks

Jan

[Qemu-discuss] Cannot opening qwoc2 image with qemu-nbd

[Pierre Couderc]

It is a XP image.

#modprobe nbd max_part=8

#qemu-nbd -c /dev/nbd0 /home/nous/qemu/xp/XPVM.qcow2

#mount /dev/nbd0p1 /media/a
mount: special device /dev/nbd0p1 does not exist

More details here :


#lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda  8:0    0 447.1G  0 disk
├─sda1   8:1    0   512M  0 part /boot/efi
├─sda2   8:2    0 434.8G  0 part /
└─sda3   8:3    0  11.9G  0 part [SWAP]
sr0 11:0    1  1024M  0 rom
nbd0    43:0    0    40G  0 disk

#fdisk -l /dev/nbd0
Disk /dev/nbd0: 40 GiB, 42949672960 bytes, 83886080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe885e885

Device  Boot Start  End  Sectors Size Id Type
/dev/nbd0p1 *   56 83866439 83866384  40G  7 HPFS/NTFS/exFAT

What am I missing

Thanks

PC

Re: [Qemu-discuss] Coldfire 5282 Support

[William Mahoney]

> On Oct 25, 2017, at 1:37 AM, Peter Maydell  wrote:
> 
> On 24 October 2017 at 21:34, William Mahoney  wrote:
>> Quick question. On the MCF5282 there is a huge memory mapped IO starting at 
>> 0x4000 and going for 1A. All of the IO is relative to this starting 
>> point, so when my call back for an I/O write happens, for example, I get the 
>> offset into the area. Fine.
> 
> What's actually in this region that wants the offset from the
> base of it? Often "all the IO is in this window" designs are
> really just "there are lots of different IO devices which
> are at different places within this range". That is, is
> there actually any behaviour needed for "in the IO range
> but not actually a device” ?

It is a “there are lots of different I/O”… design. It includes all the UARTs, 
FEC, timers, interrupt controllers (2 - more on that in a sec), … So what I 
have been doing is to start the guest and see which end up unsupported, add 
them to a switch, try again, … to see which are actually necessary for the 
board and which are not. I  do a separate region for each one but 
there’s probably 30 registers so far spread over six or seven device types. It 
just seemed simpler to consolidate. But! Since the UARTs, timers, and ethernet 
are already done, but in this range, maybe this is not the best approach?

I don’t have a problem going down this path and then, once I know what is 
needed, doing a region for each device. 

> 
>> 1) If I define the large region and THEN define the small one (since FEC 
>> support is already done), will the “more recent” region get the I/O requests 
>> and I’m good to go? And if so, will my “below the FEC” part and the “above 
>> the FEC” part still have the correct offsets?
> 
> You can do this sort of thing, but you need to define
> the region priorities (using memory_region_add_subregion_overlap()
> for at least one of them. See docs/devel/memory.txt and
> in particular the section on overlapping regions.

Ah! Good pointer, I will take a look.

Related question. Where can I go look to get a better understanding of how the 
interrupts work? The supported 5208 has one PIC but the 5282 has two. In the 
5208 code it uses sys bus_connect_irq() which references irqs[i]. (Spell 
correcting made that array called “irks”!) Just general questions like is the 
array big enough, what’s SYS_BUS_DEVICE do, ...


> 
> thanks
> -- PMM

Re: [Qemu-discuss] Coldfire 5282 Support

[Peter Maydell]

On 25 October 2017 at 15:36, William Mahoney  wrote:
>
>> On Oct 25, 2017, at 1:37 AM, Peter Maydell  wrote:
>>
>> On 24 October 2017 at 21:34, William Mahoney  wrote:
>>> Quick question. On the MCF5282 there is a huge memory mapped IO starting at 
>>> 0x4000 and going for 1A. All of the IO is relative to this starting 
>>> point, so when my call back for an I/O write happens, for example, I get 
>>> the offset into the area. Fine.
>>
>> What's actually in this region that wants the offset from the
>> base of it? Often "all the IO is in this window" designs are
>> really just "there are lots of different IO devices which
>> are at different places within this range". That is, is
>> there actually any behaviour needed for "in the IO range
>> but not actually a device” ?
>
> It is a “there are lots of different I/O”… design. It includes all the UARTs, 
> FEC, timers, interrupt controllers (2 - more on that in a sec), … So what I 
> have been doing is to start the guest and see which end up unsupported, add 
> them to a switch, try again, … to see which are actually necessary for the 
> board and which are not. I  do a separate region for each one but 
> there’s probably 30 registers so far spread over six or seven device types. 
> It just seemed simpler to consolidate. But! Since the UARTs, timers, and 
> ethernet are already done, but in this range, maybe this is not the best 
> approach?

It depends what exactly is going on, but in general each
conceptually separate device or lump of functionality
should be its own QEMU device, assuming the registers are
together rather than interleaved with each other. You may
end up with a 'misc' device for general system control.

> Related question. Where can I go look to get a better understanding of how 
> the interrupts work? The supported 5208 has one PIC but the 5282 has two. In 
> the 5208 code it uses sys bus_connect_irq() which references irqs[i]. (Spell 
> correcting made that array called “irks”!) Just general questions like is the 
> array big enough, what’s SYS_BUS_DEVICE do, ...

There's not particularly any documentation here. SYS_BUS_DEVICE
is our general abstraction for 'this is a device object with
one or more of: memory mapped registers, outbound "irq" lines,
outbound "gpio" lines, inbound "gpio" lines'. Pretty much
all devices in an embedded system are SYS_BUS_DEVICE, including
the interrupt controller. An interrupt controller is just
a device with inbound gpio lines (corresponding to the interrupt
lines from the various devices) and usually an outbound irq
line (to tell the CPU about things). The board code is then
responsible for wiring interrupt/gpio lines up from one thing
to another. (Sysbus "irq" lines and gpio lines are really
exactly the same thing under the hood, it's just convention
to use the sysbus irq APIs for device IRQ lines.)

thanks
-- PMM

Re: [Qemu-discuss] Cannot opening qwoc2 image with qemu-nbd

[Nerijus Baliūnas]

2017-10-25 17:27, Pierre Couderc rašė:

#modprobe nbd max_part=8

#qemu-nbd -c /dev/nbd0 /home/nous/qemu/xp/XPVM.qcow2

#mount /dev/nbd0p1 /media/a
mount: special device /dev/nbd0p1 does not exist


partx -a /dev/nbd0

Re: [Qemu-discuss] Coldfire 5282 Support

[William Mahoney]

Thanks Peter - thoughts below.

> On Oct 25, 2017, at 9:51 AM, Peter Maydell  wrote:
> 
> On 25 October 2017 at 15:36, William Mahoney  wrote:
>> 
>>> On Oct 25, 2017, at 1:37 AM, Peter Maydell  wrote:
>>> 
>>> On 24 October 2017 at 21:34, William Mahoney  wrote:
 Quick question. On the MCF5282 there is a huge memory mapped IO starting 
 at 0x4000 and going for 1A. All of the IO is relative to this 
 starting point, so when my call back for an I/O write happens, for 
 example, I get the offset into the area. Fine.
>>> 
>>> What's actually in this region that wants the offset from the
>>> base of it? Often "all the IO is in this window" designs are
>>> really just "there are lots of different IO devices which
>>> are at different places within this range". That is, is
>>> there actually any behaviour needed for "in the IO range
>>> but not actually a device” ?
>> 
>> It is a “there are lots of different I/O”… design. It includes all the 
>> UARTs, FEC, timers, interrupt controllers (2 - more on that in a sec), … So 
>> what I have been doing is to start the guest and see which end up 
>> unsupported, add them to a switch, try again, … to see which are actually 
>> necessary for the board and which are not. I  do a separate region 
>> for each one but there’s probably 30 registers so far spread over six or 
>> seven device types. It just seemed simpler to consolidate. But! Since the 
>> UARTs, timers, and ethernet are already done, but in this range, maybe this 
>> is not the best approach?
> 
> It depends what exactly is going on, but in general each
> conceptually separate device or lump of functionality
> should be its own QEMU device, assuming the registers are
> together rather than interleaved with each other. You may
> end up with a 'misc' device for general system control.

That makes sense. What I will do then is to continue along this path (one huge 
device) until I know for sure all of them that the board wants to use, then go 
back and make them separate regions. This seems “cleaner” in the long run 
anyway, because of the devices that are already done. Ultimately my aim 
initially is to get it far enough that I can bring up the web server, so things 
like GPIO may be dummied up.

> 
>> Related question. Where can I go look to get a better understanding of how 
>> the interrupts work? The supported 5208 has one PIC but the 5282 has two. In 
>> the 5208 code it uses sys bus_connect_irq() which references irqs[i]. (Spell 
>> correcting made that array called “irks”!) Just general questions like is 
>> the array big enough, what’s SYS_BUS_DEVICE do, ...
> 
> There's not particularly any documentation here. SYS_BUS_DEVICE
> is our general abstraction for 'this is a device object with
> one or more of: memory mapped registers, outbound "irq" lines,
> outbound "gpio" lines, inbound "gpio" lines'. Pretty much
> all devices in an embedded system are SYS_BUS_DEVICE, including
> the interrupt controller. An interrupt controller is just
> a device with inbound gpio lines (corresponding to the interrupt
> lines from the various devices) and usually an outbound irq
> line (to tell the CPU about things). The board code is then
> responsible for wiring interrupt/gpio lines up from one thing
> to another. (Sysbus "irq" lines and gpio lines are really
> exactly the same thing under the hood, it's just convention
> to use the sysbus irq APIs for device IRQ lines.)

Got it (I think). Is there a place to check the size of the IRQ table? The 5282 
has two controllers and I confess I have not read that chapter in the PDF but I 
bet that is a ton of potential requests.

> 
> thanks
> -- PMM

Re: [Qemu-discuss] Cannot opening qwoc2 image with qemu-nbd

[Pierre Couderc]

On 10/25/2017 04:57 PM, Nerijus Baliūnas wrote:

partx -a /dev/nbd0
Thank you very much. There are many incomplete howto on the web... Imake 
a tutorial (on the web) for myself first.