[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] VGA Passthrough crashes machine



On 15/12/2011 21:12, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 15, 2011 at 03:54:00PM +0000, Anthony Wright wrote:
>> On 14/12/2011 21:38, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Dec 08, 2011 at 12:00:07PM +0000, Anthony Wright wrote:
>>>> I've just had my first attempt at getting VGA passthrough to work, and
>>>> it crashed the machine. I'm trying to understand whether this is a
>>>> problem with my hardware, configuration or a software problem.
>>>>
>>>> I'm running Xen 4.1.2 with Linux 3.1.2
>>>>
>>>>
>>>> The CPU is an Intel Core i5-650
>>>> http://ark.intel.com/products/43546/Intel-Core-i5-650-Processor-%284M-Cache-3_20-GHz%29
>>> And what is your motherboard? Does it have VT-d?
>> That was the important question... I'd missed the BIOS option to enable
>> VT-d which was disabled by default. I enabled the BIOS option and
>> everything worked, and it's very cool. :-)
>>
>> This does beg a couple of other questions though....
>>
>> Shouldn't I get a nice(ish) error message if I try to start a VGA
>> passthrough VM on hardware that doesn't support it rather than crashing
>> the machine?
>
> There is this http://wiki.xen.org/xenwiki/VTdHowTo which gives you a
> nice idea of what works.
Unfortunately I spoke a little too soon. I'm running with a Windows 7
Pro, 32 bit iso image, to install a new version of windows into the VM.
It seems to start nicely and I get a pulsing windows logo on the screen,
but it never progresses to the next page, and the VM consumes a huge
amount of CPU. If I run it purely in a VNC session, everything runs
smoothly and quickly. We noticed that there are a lot of VT-d features
disabled, and wondered if this might be the cause. The motherboard is an
intel DQ57TM, and the processor is an Intel Core i5-650, I have enabled
VT-d and FLR within the motherboard which seem to be the only relevant
motherboard switches.

Inside xl dmesg all the additional VT-d features are not enabled (Snoop
Control, Dom0 DMA Passthrough, Queued Invalidation, Interrupt Remapping,
Shared EPT tables) and I wondered if this was the problem. I tried
starting with iommu=1 on the xen command line and without it. The output
from xl dmesg is very similar and the VM behaves the same in both cases,
but I get a number of iommu.c errors messages when the 'iommu=1'
parameter is present. In both cases Xen also outputs a number of mm.c
errors which is similar to a problem I reported a while ago. I have
attach xl dmesg logs from both cases.

>> Can I tell whether hardware will support VGA passthrough without trying
>> to start a VM that uses it?
>>
>> Also when I shut down the VM I have to use 'xl destroy' as I'm testing
>> with Windows. After issuing the 'xl destroy' there is a long pause and
>> then the error:
>>
>>     libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device
>> Model not ready
>>     libxl: error: libxl_pci.c:892:do_pci_remove Device Model didn't
>> respond in time
>>
>> If I pass through more than one device, I get the pause and the message
>> for each device.
> Hm, it looks to be sending 'pci-rem' to the XenStore, but I am not sure
> if QEMU understands it. Did you compile Xen 4.1.2 by yourself? Did it
> compile with CONFIG_PASSTHROUGH?
>
> You should see some messages in the qemu.log about hot-remove and such.
Yes I compiled Xen 4.1.2 by myself, but I don't know is
CONFIG_PASSTHROUGH is enabled or not - there's no mention of it in the
build logs. I see a hot-remove entry in the qemu log, and have attached
the whole log as it's not very long.

Anthony.

Attachment: qemu-dm-16-2.log
Description: Text document

Attachment: xl-dmesg-blank
Description: Text document

Attachment: xl-dmesg-iommu
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.