Re: Fwd: Re: Xen 4.3 / 4.4 - concurrent APIs, VGA Passthru

[Georg Bege <therion@ninth-art.de>]

Hello again

Well so far I can now tell, I tested it on WinXP x64 quite a lot
- most things are working.
Including AAA games like Witcher 2, I didnt try a very memory consuming
game yet.
But I dont really think that I have the same bug you are refering to -
in WinXP x64 the /PATCHTPR boot flag did help greatly, it really boosted
the performance to near native.
I dont think I encountered any memory usage, used like applications
consuming the first 4GB of the DomU.

Im trying to figure what to do for Windows 7, its working good too -
even with VGA Passthrough,
but its almost always consuming 33%-80% CPU usage for no reason...

I also stumpled upon the issue that if you reboot a VGA Passthru DomU
then that the GFX adapter looses performance (which was explained
somewhere in the docs already).
Atm. all this is done with Xen 4.4 - Im not sure why I would go back to
Xen 4.3, Xen is improving greatly over each version I think, that older
versions have more (unfixed) issues is quite logical.

I just wonder what I can do for Win7 performance wise so that I can test
things like Borderlands 2 you referred to... or any other high memory
usage application.

regards,
Georg

Am 29.07.2014 14:22, schrieb Gordan Bobic:
> On 2014-07-29 12:52, Georg Bege wrote:
>> Am 29.07.2014 12:38, schrieb Gordan Bobic:
>>> On 2014-07-29 08:39, Georg Bege wrote:
>>>> Am 29.07.2014 09:10, schrieb Gordan Bobic:
>>>>> On 07/29/2014 02:12 AM, Georg Bege wrote:
>
>>>>>> no with Xen 4.3 its not working to me, in Win XP64 I get kinda
>>>>>> abstract
>>>>>> distortions in the screen,
>>>>>
>>>>> That sounds suspiciously like the IOMEM memory stomp I see with my
>>>>> motherboard.
>>>>>
>>>>>> not much later then I get a kernel panic on Dom0 regarding IRQ16
>>>>>> (like
>>>>>> sth IRC16: no body cared.. oops) the kernel gets damaged by it and
>>>>>> then
>>>>>> the whole machine works like in slow-motion (everything X11,
>>>>>> moving of
>>>>>> the mouse etc.) all I can do then is hard reboot...
>>>>>
>>>>> I have seen the interrupt issue before but _only_ when I xl destroy
>>>>> the domUs. It never happened on a clean shutdown/reboot of domUs. The
>>>>> interrupt you mention - does it happen to be the IRQ used by your USB
>>>>> controller?
>>>> Im not sure but the IRQ 16 is used by:
>>>>  16:    2065542          0          0          0          0
>>>> 0          0          0  xen-pirq-ioapic-level  ehci_hcd:usb1,
>>>> snd_emu10k1, nouveau
>>>
>>> ehci_hcd:usb1 sounds like USB.
>>>
>>> If you look at lspci -vvv, look for "IRQ 16". It should match.
>>>
>> Yes you're right, it is - however Im quite suprised how many devices
>> share that same Interrupt.
>>
>> Interrupt: pin A routed to IRQ 16:
>>
>> 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2
>> Enhanced Host Controller #2 (rev 05) (prog-if 20 [EHCI])
>> 02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
>> Controller (rev 04) (prog-if 30 [XHCI])
>> 03:00.0 VGA compatible controller: NVIDIA Corporation GF100GL [Quadro
>> 5000] (rev a3) (prog-if 00 [VGA controller])
>> 04:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce
>> 210] (rev a2) (prog-if 00 [VGA controller])
>> 05:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic
>> SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)
>> 0a:00.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1
>> (rev 04)
>>
>> Is this normal?
>
> It sounds a bit high, but it's not implausible.
>
> On my machine this shows:
> for irq in `lspci -vvv | grep IRQ | sed -e 's/.*IRQ //' | sort -un`; do
>   echo -n "IRQ $irq: ";
>   lspci -vvv | grep IRQ | sed -e 's/.*IRQ //' | grep "^$irq$" | wc -l;
> done
>
> IRQ 16: 1
> IRQ 18: 3
> IRQ 19: 2
> IRQ 21: 1
> IRQ 22: 1
> IRQ 23: 2
> IRQ 24: 2
> IRQ 29: 1
> IRQ 36: 1
> IRQ 37: 1
> IRQ 38: 1
> IRQ 39: 1
> IRQ 40: 1
> IRQ 212: 1
> IRQ 213: 1
> IRQ 214: 1
> IRQ 215: 1
>
> So IRQ 18 is used by 3 devices, all of which are on the
> ICH10 SB chip (2x USB, 1x SMBus).
>
> What surprises me slightly more is the devices that are
> sharing IRQs on your system. It almost looks like at least 4
> PCIe slots are sharing the same interrupt, which is somewhat
> unusual.
>
>> I've to check out the other stuff, I'll reply again once I did that -
>> but might take till tomorrow.
>
> Please do. I'd be interested to hear if you are in fact
> hitting the same bug as me, as it is rather obscure and
> unusual.
>
> Gordan