Re: [Xen-devel] XCI: can we get to the demo state?

[Tom Rotenberg <tom.rotenberg@xxxxxxxxx>]

Did the Aero worked for you on the nVidia/ATI or on the Intel IGD?

On Wed, Aug 19, 2009 at 12:17 AM, Phung Te Ha<phungte@xxxxxxxxx> wrote:
> Hi all,
>
> I tried and gave up on building a xenclient_usb.config, the build broke at
> quite many places. So I use file as disk:
>
> disk = /mnt/3/vista_image.bin:file:hda:w:disk
>
> first started a vista installation from DVD, then continued on, setup the
> network, download the graphics driver from hp.com, and aero showed after
> reboot!!!
>
> Thanks for your help.
>
> Phung-Te
>
> On Mon, Aug 17, 2009 at 12:09 PM, Phung Te Ha <phungte@xxxxxxxxx> wrote:
>>
>> Hi all,
>>
>> Thanks to your helps, I could see vista come up from a DVD installation
>> with the graphics controller passed-through. The machine I am using is
>> HP6930p. The config is Ross', just changed the disk from:
>>
>> disk = /dev/sda:phy:hda:w:disk
>>
>> to
>>
>> disk = /dev/sr0:phy:hdd:r:cdrom
>>
>> I also have vista on the disk at /dev/sda1. But since I use the same disk
>> to boot xenclient, when I start the guest, giving /dev/sda as disk, grub
>> wants to boot xenclient again, instead of vista.
>>
>> So now I am building a xenclient_usb config, and leave /dev/sda to vista
>> only.
>>
>> Will update.
>>
>> Phung-Te
>>
>>
>> On Fri, Aug 14, 2009 at 2:15 PM, Ross Philipson
>> <Ross.Philipson@xxxxxxxxxx> wrote:
>>>
>>> Yes, I am passing the graphics through. I am using an HP 6930p at the
>>> moment. I am using Windows Vista as the VM I am passing the graphics through
>>> to and using Windows XP in a second VM that I am using VNC for. I attached
>>> the xenvm config files I happen to be using right now. Note that my Vista
>>> install is not a vhd but rather installed on a partition on disk.
>>>
>>>
>>>
>>> Ross
>>>
>>>
>>>
>>> From: Phung Te Ha [mailto:phungte@xxxxxxxxx]
>>> Sent: Friday, August 14, 2009 4:18 PM
>>>
>>> To: Ross Philipson
>>> Cc: Vincent Hanquez; xen-devel@xxxxxxxxxxxxxxxxxxx; Kamala Narasimhan
>>> Subject: Re: [Xen-devel] XCI: can we get to the demo state?
>>>
>>>
>>>
>>> Do you pass the graphics controller through? Which guest are you using?
>>> Do you mind publish your config file?
>>>
>>> Thank you.
>>>
>>> Phung-Te
>>>
>>> On Fri, Aug 14, 2009 at 11:08 AM, Ross Philipson
>>> <Ross.Philipson@xxxxxxxxxx> wrote:
>>>
>>> Well we don’t have a official list we can push but we run on the same HP
>>> 6930p you have all the time. We have also had it running on Intel Q35
>>> systems. So in general it should work on these systems.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Ross
>>>
>>>
>>>
>>> From: Phung Te Ha [mailto:phungte@xxxxxxxxx]
>>> Sent: Friday, August 14, 2009 11:32 AM
>>> To: Ross Philipson
>>> Cc: Vincent Hanquez; xen-devel@xxxxxxxxxxxxxxxxxxx; Kamala Narasimhan
>>>
>>> Subject: Re: [Xen-devel] XCI: can we get to the demo state?
>>>
>>>
>>>
>>> Hello all,
>>>
>>> The only thing I passed through was the graphics controller.
>>> After starting the guest, the system is still there running, xenops
>>> list_domains shows 2 doms running, but nothing from the guest is showing.
>>>
>>> The board I am using is the Intel DQ35OJ and the graphics controller is
>>> the onboard one. Same operation has also been done on a HP6930p, same
>>> result. Can you publish the list of hardware you guys are using, MB,
>>> graphics board..., the config that most likely to get a graphics controller
>>> passed through.
>>>
>>> Thank you.
>>>
>>> Phung-Te
>>>
>>> On Fri, Aug 14, 2009 at 7:13 AM, Ross Philipson
>>> <Ross.Philipson@xxxxxxxxxx> wrote:
>>>
>>> Yeah, these occur when the iommu context for the device in question (in
>>> this case your iGfx card) has been torn down but the card is still active
>>> (still attempting DMA). The code in xen to perform an function level resets
>>> (FLR) on the devices takes care of the vast majority of these but there
>>> still remain one or two that occur even thought the FLR has been done. This
>>> issue was never resolved but these few remaining faults don't seem to cause
>>> a problem. So you are experiencing a hang as the vm starts I take it. Is the
>>> vtd fault trace the last thing you see? Are you passing anything else
>>> through?
>>>
>>> Thanks
>>> Ross
>>>
>>> -----Original Message-----
>>> From: Vincent Hanquez
>>> Sent: Friday, August 14, 2009 7:05 AM
>>> To: Phung Te Ha
>>>
>>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Ross Philipson; Kamala Narasimhan
>>> Subject: Re: [Xen-devel] XCI: can we get to the demo state?
>>>
>>> Phung Te Ha wrote:
>>> > Hi Vincent,
>>> >
>>> > I tried your suggestion, adding pci = 0,bind,0000:00:02.0 in the config
>>> > on 2 different machines, the HP6930 and on an Intel MB DQ35OJ.
>>> >
>>> > On both machines, I got the samething, the guest run as shown by
>>> > xenops list_domains:
>>> >
>>> >  id |  state |    cpu_time |                                 uuid
>>> >  0 |     R  | 54203470658 | 00000000-0000-0000-0000-000000000000
>>> >  1 |    B H | 12214238864 | 00000000-0000-0000-0000-000000000002
>>> >
>>> > But nothing shows on the screen.
>>> >
>>> > I checked the logs and found in xenops dmesg:
>>> >
>>> > ...
>>> > (XEN) Intel VT-d Snoop Control not supported.
>>> > (XEN) Intel VT-d DMA Passthrough not supported.
>>> > (XEN) Intel VT-d Queued Invalidation not supported.
>>> > (XEN) Intel VT-d Interrupt Remapping not supported.
>>> > (XEN) I/O virtualisation enabled
>>> > (XEN) I/O virtualisation for PV guests disabled
>>> >
>>> >
>>> > And when the guest is started:
>>> >
>>> > ...
>>> >  _fault:DMA Write: 0:2.0 addr faddf7000 REASON 5 iommu->reg =
>>> > ffff828bfff56000
>>> > (XEN) print_vtd_entries: iommu = ffff83007dcfb320 bdf = 0:2:0 gmfn =
>>> > faddf7
>>> > (XEN)     root_entry = ffff83007e0ce000
>>> > (XEN)     root_entry[0] = 7e066001
>>> > (XEN)     context = ffff83007e066000
>>> > (XEN)     context[10] = 201_7da02001
>>> > (XEN)     l3 = ffff83007da02000
>>> > (XEN)     l3_index = 3e
>>> > (XEN)     l3[3e] = 0
>>> > (XEN)     l3[3e] not present
>>> > (XEN) [VT-D]iommu.c:722: iommu_page_fault: iommu->reg =
>>> > ffff828bfff56000
>>> > (XEN) [VT-D]iommu.c:691: iommu_fault_status: Fault Overflow
>>> > (XEN) [VT-D]iommu.c:694: iommu_fault_status: Primary Pending Fault
>>> > (XEN) [VT-D]iommu.c:676: iommu_fault:DMA Write: 0:2.0 addr faddf7000
>>> > REASON 5 iommu->reg = ffff828bfff56000
>>> > (XEN) print_vtd_entries: iommu = ffff83007dcfb320 bdf = 0:2:0 gmfn =
>>> > faddf7
>>> > (XEN)     root_entry = ffff83007e0ce000
>>> > (XEN)     root_entry[0] = 7e066001
>>> > (XEN)     context = ffff83007e066000
>>> > ...
>>> >
>>> > Do you think these 2 machines have enough of VT-d features to get the
>>> > graphics passed-through?
>>> > Do you have a preferred desktop board, known to work for graphisc
>>> > passed-through?
>>> I'm not really familiar with thoses VT-d errors. Kamala/Ross do you have
>>> any idea, what this previous errors means ?
>>>
>>> thanks,
>>> --
>>> Vincent
>>>
>>>
>>>
>>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>

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