Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release

Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release

[Fabio Fantoni]

Il 18/09/2013 16:30, Jan Beulich ha scritto:
>>>> On 18.09.13 at 16:12, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>> Il 18/09/2013 14:42, Jan Beulich ha scritto:
>>>>>> On 18.09.13 at 14:29, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>> I not see the MMIO error on logs, what must I do to see it or any
>>>> similar debug information?
>>>> Tell me if I must do other specific test or you need other details.
>>> Without the patch you ought to have seen "bad mmio size ..."
>> I was unable to see the MMIO error on each log files also before the patch.
>> I don't know if I have enable sufficent debug to log them.
>> And I have no ideaon how to do it.
> This is a guest warning (from log level perspective), so by default
> would be visible in a rate limited fashion. If you want to be certain,
> just add "loglvl=all guest_loglvl=all". But I'm more and more
> convinced that the information we got from you originally was
> misleading.

On grub.cfg now I have:
...
multiboot       /boot/xen.gz placeholder dom0_mem=4G,max:4G loglvl=all 
guest_loglvl=all
...
But I'm unable to see debug related information in log files.
This was the test of Anthony Perard with all details about the problem:
http://lists.xen.org/archives/html/xen-devel/2013-05/msg02050.html

So my questions are:
- Is your patch aimed to completely solve cpus instrictions with MMIO 
operands > 8 byte or
- does it need also some qemu changes?
I also added qemu-devel and anthony perard on cc.
Thanks for any reply.


>
>> Is there another method to test effettive working of SSE >=2 istructions?
> You realize that we're not talking about arbitrary SSE instructions,
> but only such with their memory operand being in MMIO space.
> Anything else doesn't hit the emulator.
> Jan
>

Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release

[Jan Beulich]

>>> On 18.09.13 at 17:26, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
> Il 18/09/2013 16:30, Jan Beulich ha scritto:
>>>>> On 18.09.13 at 16:12, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>> Il 18/09/2013 14:42, Jan Beulich ha scritto:
>>>>>>> On 18.09.13 at 14:29, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>>> I not see the MMIO error on logs, what must I do to see it or any
>>>>> similar debug information?
>>>>> Tell me if I must do other specific test or you need other details.
>>>> Without the patch you ought to have seen "bad mmio size ..."
>>> I was unable to see the MMIO error on each log files also before the patch.
>>> I don't know if I have enable sufficent debug to log them.
>>> And I have no ideaon how to do it.
>> This is a guest warning (from log level perspective), so by default
>> would be visible in a rate limited fashion. If you want to be certain,
>> just add "loglvl=all guest_loglvl=all". But I'm more and more
>> convinced that the information we got from you originally was
>> misleading.
> 
> On grub.cfg now I have:
> ...
> multiboot       /boot/xen.gz placeholder dom0_mem=4G,max:4G loglvl=all 
> guest_loglvl=all
> ...
> But I'm unable to see debug related information in log files.

Log files? There can be a pertinent log file only if you have some
daemon running transferring the hypervisor log into a log file.
Otherwise you need to look at "xl dmesg" output.

> This was the test of Anthony Perard with all details about the problem:
> http://lists.xen.org/archives/html/xen-devel/2013-05/msg02050.html 

See the "bad mmio size 16" and "MMIO emulation failed @ ..."
messages there?

> So my questions are:
> - Is your patch aimed to completely solve cpus instrictions with MMIO 
> operands > 8 byte or
> - does it need also some qemu changes?

The patch is aiming at completely solving the in-hypervisor
emulation issues with operands of more than 8 bytes in size.

Whether on top of that a qemu change is also necessary I
don't know, but I wouldn't have expected so.

Jan

Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release

[Fabio Fantoni]

[-- Attachment #1: Type: text/plain, Size: 7472 bytes --]

Il 18/09/2013 17:35, Jan Beulich ha scritto:
>>>> On 18.09.13 at 17:26, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>> Il 18/09/2013 16:30, Jan Beulich ha scritto:
>>>>>> On 18.09.13 at 16:12, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>> Il 18/09/2013 14:42, Jan Beulich ha scritto:
>>>>>>>> On 18.09.13 at 14:29, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>>>> I not see the MMIO error on logs, what must I do to see it or any
>>>>>> similar debug information?
>>>>>> Tell me if I must do other specific test or you need other details.
>>>>> Without the patch you ought to have seen "bad mmio size ..."
>>>> I was unable to see the MMIO error on each log files also before the patch.
>>>> I don't know if I have enable sufficent debug to log them.
>>>> And I have no ideaon how to do it.
>>> This is a guest warning (from log level perspective), so by default
>>> would be visible in a rate limited fashion. If you want to be certain,
>>> just add "loglvl=all guest_loglvl=all". But I'm more and more
>>> convinced that the information we got from you originally was
>>> misleading.
>> On grub.cfg now I have:
>> ...
>> multiboot       /boot/xen.gz placeholder dom0_mem=4G,max:4G loglvl=all
>> guest_loglvl=all
>> ...
>> But I'm unable to see debug related information in log files.
> Log files? There can be a pertinent log file only if you have some
> daemon running transferring the hypervisor log into a log file.
> Otherwise you need to look at "xl dmesg" output.

Thanks for reply.
This is logs from xl dmesg about Quantal (ubuntu 12.10) hvm domU with 
qxl vga and patch "x86-HVM-emul-split-large":

> (d3) HVM Loader
> (d3) Detected Xen v4.4-unstable
> (d3) Xenbus rings @0xfeffc000, event channel 4
> (d3) System requested SeaBIOS
> (d3) CPU speed is 2661 MHz
> (d3) Relocating guest memory for lowmem MMIO space disabled
> (XEN) irq.c:270: Dom3 PCI link 0 changed 0 -> 5
> (d3) PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:270: Dom3 PCI link 1 changed 0 -> 10
> (d3) PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:270: Dom3 PCI link 2 changed 0 -> 11
> (d3) PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:270: Dom3 PCI link 3 changed 0 -> 5
> (d3) PCI-ISA link 3 routed to IRQ5
> (d3) pci dev 01:3 INTA->IRQ10
> (d3) pci dev 02:0 INTA->IRQ11
> (d3) pci dev 03:0 INTA->IRQ5
> (d3) pci dev 04:0 INTA->IRQ5
> (d3) No RAM in high memory; setting high_mem resource base to 100000000
> (d3) pci dev 02:0 bar 10 size 004000000: 0f0000000
> (d3) pci dev 02:0 bar 14 size 004000000: 0f4000000
> (d3) pci dev 03:0 bar 14 size 001000000: 0f8000008
> (d3) pci dev 04:0 bar 30 size 000040000: 0f9000000
> (d3) pci dev 02:0 bar 30 size 000010000: 0f9040000
> (d3) pci dev 02:0 bar 18 size 000002000: 0f9050000
> (d3) pci dev 03:0 bar 10 size 000000100: 00000c001
> (d3) pci dev 04:0 bar 10 size 000000100: 00000c101
> (d3) pci dev 04:0 bar 14 size 000000100: 0f9052000
> (d3) pci dev 02:0 bar 1c size 000000020: 00000c201
> (d3) pci dev 01:1 bar 20 size 000000010: 00000c221
> (d3) Multiprocessor initialisation:
> (d3)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (d3)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (d3) Testing HVM environment:
> (d3)  - REP INSB across page boundaries ... passed
> (d3)  - GS base MSRs and SWAPGS ... passed
> (d3) Passed 2 of 2 tests
> (d3) Writing SMBIOS tables ...
> (d3) Loading SeaBIOS ...
> (d3) Creating MP tables ...
> (d3) Loading ACPI ...
> (d3) vm86 TSS at fc00a080
> (d3) BIOS map:
> (d3)  10000-100d3: Scratch space
> (d3)  e0000-fffff: Main BIOS
> (d3) E820 table:
> (d3)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> (d3)  HOLE: 00000000:000a0000 - 00000000:000e0000
> (d3)  [01]: 00000000:000e0000 - 00000000:00100000: RESERVED
> (d3)  [02]: 00000000:00100000 - 00000000:78000000: RAM
> (d3)  HOLE: 00000000:78000000 - 00000000:fc000000
> (d3)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
> (d3) Invoking SeaBIOS ...
> (d3) SeaBIOS (version 
> debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-vfarm)
> (d3)
> (d3) Found Xen hypervisor signature at 40000000
> (d3) xen: copy e820...
> (d3) Relocating init from 0x000e2001 to 0x77fe0600 (size 63795)
> (d3) CPU Mhz=2662
> (d3) Found 7 PCI devices (max PCI bus is 00)
> (d3) Allocated Xen hypercall page at 77fff000
> (d3) Detected Xen v4.4-unstable
> (d3) xen: copy BIOS tables...
> (d3) Copying SMBIOS entry point from 0x00010010 to 0x000f1920
> (d3) Copying MPTABLE from 0xfc001170/fc001180 to 0x000f1820
> (d3) Copying PIR from 0x00010030 to 0x000f17a0
> (d3) Copying ACPI RSDP from 0x000100b0 to 0x000f1770
> (d3) Using pmtimer, ioport 0xb008, freq 3579 kHz
> (d3) Scan for VGA option rom
> *(d3) WARNING! Found unaligned PCI rom (vd=1b36:0100)* ***
> (d3) Running option rom at c000:0003
> *(XEN) stdvga.c:147:d3 entering stdvga and caching modes* ***
> (d3) Turning on vga text mode console
> (d3) SeaBIOS (version 
> debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-vfarm)
> (d3) Machine UUID c0d117cd-4e25-47c9-b6cb-2fa70dfd551c
> (d3) Found 1 lpt ports
> (d3) Found 1 serial ports
> (d3) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> (d3) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> (d3) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (12000 MiBytes)
> (d3) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> (d3) DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
> (d3) Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
> (d3) PS2 keyboard initialized
> (d3) All threads complete.
> (d3) Scan for option roms
> (d3) Running option rom at ca00:0003
> (d3) pmm call arg1=1
> (d3) pmm call arg1=0
> (d3) pmm call arg1=1
> (d3) pmm call arg1=0
> (d3) Searching bootorder for: /pci@i0cf8/*@4
> (d3)
> (d3) Press F12 for boot menu.
> (d3)
> (d3) Searching bootorder for: HALT
> (d3) drive 0x000f1720: PCHS=16383/16/63 translation=lba 
> LCHS=1024/255/63 s=24576000
> (d3) Space available for UMB: cb000-ee800, f0000-f16c0
> (d3) Returned 61440 bytes of ZoneHigh
> (d3) e820 map has 6 items:
> (d3)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
> (d3)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
> (d3)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
> (d3)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
> (d3)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
> (d3)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
> (d3) enter handle_19:
> (d3)   NULL
> (d3) Booting from Hard Disk...
> (d3) Booting from 0000:7c00
> (XEN) hvm.c:1213:d3 All CPUs offline -- powering off.

qemu seem to crash at domU's xorg loading, nothing on logs about the 
crash, only the last line added on xl dmesg above and on qemu log:
qemu: terminating on signal 1 from pid 8485

I found strange things on xl dmesg logs above about domU (I put it in 
bold and starred).
Thanks for any reply.


>
>> This was the test of Anthony Perard with all details about the problem:
>> http://lists.xen.org/archives/html/xen-devel/2013-05/msg02050.html
> See the "bad mmio size 16" and "MMIO emulation failed @ ..."
> messages there?
>
>> So my questions are:
>> - Is your patch aimed to completely solve cpus instrictions with MMIO
>> operands > 8 byte or
>> - does it need also some qemu changes?
> The patch is aiming at completely solving the in-hypervisor
> emulation issues with operands of more than 8 bytes in size.
>
> Whether on top of that a qemu change is also necessary I
> don't know, but I wouldn't have expected so.

Someone qemu maintainer on this?
Thanks for any reply.

>
> Jan
>


[-- Attachment #2: Type: text/html, Size: 10790 bytes --]

Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release

[Jan Beulich]

>>> On 19.09.13 at 11:22, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
> This is logs from xl dmesg about Quantal (ubuntu 12.10) hvm domU with 
> qxl vga and patch "x86-HVM-emul-split-large":
> 
>> (d3) HVM Loader
>> [...]

So in particular no wrong mmio size messages.

> qemu seem to crash at domU's xorg loading, nothing on logs about the 
> crash, only the last line added on xl dmesg above and on qemu log:
> qemu: terminating on signal 1 from pid 8485
> 
> I found strange things on xl dmesg logs above about domU (I put it in 
> bold and starred).

I can't say anything about those. Once again, with qemu issues
(and tools ones in general) i have to defer to the respective
experts.

Jan

Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release

[George Dunlap]

On 19/09/13 11:01, Jan Beulich wrote:
>>>> On 19.09.13 at 11:22, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>> This is logs from xl dmesg about Quantal (ubuntu 12.10) hvm domU with
>> qxl vga and patch "x86-HVM-emul-split-large":
>>
>>> (d3) HVM Loader
>>> [...]
> So in particular no wrong mmio size messages.
>
>> qemu seem to crash at domU's xorg loading, nothing on logs about the
>> crash, only the last line added on xl dmesg above and on qemu log:
>> qemu: terminating on signal 1 from pid 8485
>>
>> I found strange things on xl dmesg logs above about domU (I put it in
>> bold and starred).
> I can't say anything about those. Once again, with qemu issues
> (and tools ones in general) i have to defer to the respective
> experts.

Fabio,

I think back when Anthony Perard looked at this, he found that there was 
a field not being initialized in qemu that caused it to crash when using 
qxl.  I think the fix was just a one-line patch -- do you have that 
patch applied to your copy of qemu?

  -George

Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release

[Fabio Fantoni]

Il 19/09/2013 12:04, George Dunlap ha scritto:
> On 19/09/13 11:01, Jan Beulich wrote:
>>>>> On 19.09.13 at 11:22, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>> This is logs from xl dmesg about Quantal (ubuntu 12.10) hvm domU with
>>> qxl vga and patch "x86-HVM-emul-split-large":
>>>
>>>> (d3) HVM Loader
>>>> [...]
>> So in particular no wrong mmio size messages.
>>
>>> qemu seem to crash at domU's xorg loading, nothing on logs about the
>>> crash, only the last line added on xl dmesg above and on qemu log:
>>> qemu: terminating on signal 1 from pid 8485
>>>
>>> I found strange things on xl dmesg logs above about domU (I put it in
>>> bold and starred).
>> I can't say anything about those. Once again, with qemu issues
>> (and tools ones in general) i have to defer to the respective
>> experts.
>
> Fabio,
>
> I think back when Anthony Perard looked at this, he found that there 
> was a field not being initialized in qemu that caused it to crash when 
> using qxl.  I think the fix was just a one-line patch -- do you have 
> that patch applied to your copy of qemu?
>
>  -George

Thanks for reply.
The anthony fix was accepted time ago on qemu git:
http://git.qemu.org/?p=qemu.git;a=commit;h=329f97fc4ff4b533fcd2d8f4eab6c9c2568aed27
I use qemu 1.6 that include also this patch on my latest tests.

About the bold line on xl dmesg of previous mail, (relative to 
xen/arch/x86/hvm/stdvga.c) I think that could be cause of potential 
problem with qxl which has different hardware structures, but I not have 
sufficent knownoledge about to found if this need a change and where.

About qxl hardware structure information I found only this details on 
qemu mailing list time ago:
> The qxl device has two large memory regions:
>
> Region #1 is called "ram" and is mapped to PCI bar 0.  This is again
> splitted into three parts:  The framebuffer at the start, the command
> rings at the end, and storage area for spice rendering commands and
> image data inbetween.
>
> Region #2 is called "vram".  This is storage for images, called
> "surfaces" in spice.  Surfaces can be both source and target for spice
> rendering operations.  X11 can store offscreen pixmaps there for
> example.  Once qxl gets 3D support surfaces can also be used for textures.
>
> Now for the properties:
>
> vgamem_mb
>    specifies the size of the framebuffer portion of the "ram" region, in
>    megabytes.  Must be big enougth to hold the maximum display
>    resolution you want to use.  Replaces the fixed VGA_RAM_SIZE define.
>    Default is 8 or 16 MB depending on machine type with all patches of
>    this series applied (see last patch).
>
> ram_size_mb
>    specifies the total size of the "ram" region, in megabytes.  Defaults
>    to 64 MB.  Must be larger than vgamem_mb obviously.
>
> vram_size_mb
>    specifies the total size of the "vram" region, in megabytes.
>    Defaults to 64 MB.
>
> vram64_size_mb
>    if this one is present and larger than vram_size_mb qxl will get an
>    additional 64bit pci bar.  Both 32bit and 64bit vram pci bars are
>    backed by the "vram" memory region, the 32bit bar is an alias mapping
>    for the first part of the 64bit pci bar.  This can be used to give
>    guests *lots* of vram without exhausting 32bit pci address space.
>    Obviously only useful for 64bit guests.  Requires cutting edge
>    seabios to get the 64bit bar actually mapped above 4G.
>
> ram_size
>    specifies the total size of the "ram" region, in bytes.  For
>    compatibility with older qemu versions, ignored if ram_size_mb
>    property is present.
>
> vram_size
>    specifies the total size of the "vram" region, in bytes.  For
>    compatibility with older qemu versions, ignored if vram_size_mb
>    property is present.
i hope this can help to understand if is needed other change on xen side.

Thanks for any reply.