On 23.01.2013 17:41, bradbury9 wrote:
> Joanna, Marek, thanks for the info, greatly appreciated.
>
> I will try Joanna advice and, if failed, Marek's one. Will have two gaming
> HVM
>
> One for a fedora17 (or ubuntu) HVM. Steam has Fedora 17 and ubuntu
> packages/repo (with debian or mint some tweaks must be done to the deb
> package, wrong dependencies on the Steam deb package) so with the correct
> packages should work fine.
> The other one for HVM (windows) using qvm-pci.
>
> My plan is to get the hardware in about a couple of months, will let you
> know if works fine, emailing to update HCL.
>
> Many games try to get fullscreen, would it cause problems with the HVM?

El jueves, 24 de enero de 2013 18:01:59 UTC+1, Alex Dubois escribió:

El viernes, 15 de febrero de 2013 20:16:30 UTC+1, bradbury9 escribió:

Just tried passing GPU with "qvm-pci -a"... It turns out there is some problem passing GPU via qvm-pci. Looks like Xen does not like it very much when it comes with GPU's.

$qvm-start gamingLinux

libxl: error: libxl_pci.c:767:libxl_device_pci_reset The kernel doesn't support reset from sysfs for PCI device 0000:01:00.0
libxl: error: libxl_pci.c:726:do_pci_add xc_assign_device failed
libxl: error: libxl_pci.c:477:libxl__wait_for_device_model Device Model not ready
libxl: error: libxl_pci.c:641:libxl__pci_notify_device_model qemu refused to add device: 0000:01:00.0

The GPU is a Geforce GTX 680. Is there any qvm-pci option or can the HVM config files be edited to make Xen allow those commands?

On 03/04/13 11:42, Cosmic Charade wrote:
> If I am reading this correctly, I have to pass through graphics from
> Windows to Xen (which is what I was thinking before I re-read this so maybe
> it now makes sense).
>
> Ideally, there would be some driver I could just install in Windows that
> handles all that.
>

> What about the hypervisor itself, doesn't that need an Nvidia hardware
> level driver?

>  At the moment it looks like the VM's are all software
> rendered, I'm not sure how I'd check though.
>

> On Sunday, 3 March 2013 23:02:47 UTC+11, bradbury9 wrote:
>>
>>
>> Forwarding to the list ;-)
>>
>> ---------- Forwarded message ----------

>> From: gorka - <ray.br...@gmail.com <javascript:>>
>> Date: 2013/3/3
>> Subject: Re: GPU passing to HVM (was: Re: [qubes-devel] Re: Question about
>> windows HVM)

On 03/04/13 15:38, bradbury9 wrote:
> Please, correct me if my guess is wrong.
>
> Qubes: Xen is installed under linux. Runs windows VM

On Thu, Mar 7, 2013 at 5:44 AM, Cosmic Charade <cosmic...@gmail.com> wrote:
> OK this is my lack of technical understanding coming through.
>
> So the Xen hypervisor does *not* require a graphics driver, but each VM
> does?  What would happen if I installed the Linux Nvidia binary driver in
> the Fedora default VM's, and the binary Nvidia driver in a Windows 8 VM?
> Wouldn't they clash or something?  I don't want to play games (I'll use a
> bare metal Windows for that), but I may want to watch some basic / streaming
> media or full screen video (not DRM protected blu-ray's - but possibly .mkv
> or other video files).

On Thursday, 7 March 2013 17:50:10 UTC+11, Radosław Szkodziński wrote:

You can redirect the GPU only to one virtual machine at a time. The
real question is whether the driver correctly resets the card, so you
can attach it again.

 

For example Catalyst drivers did not (10.12 or so - first version with
Radeon 7950 support) - but xm's old way of reset worked well. Perhaps
someone should patch that into xl as well for cards w/o FLR like that
one.

 

Theoretically Qubes GUId may be just about fast enough for full screen
video, if your CPU is fast enough to decode it in software with some
remaining power, as the GUI protocol is relatively CPU intensive.

 

It is too slow for fullscreen Flash though - that thing has very slow
software decoding and/or scaling.
(CPU here: Xeon E3 1275)

--
Radosław Szkodziński

That blows...

Is there any way to compensate for the lack of a reset command in NVidia cards?

I'm fine with hardware lock to each VM as they are used although I'm not sure how this would work with windows from different VMs displaying simultaneously.

That blows...

Is there any way to compensate for the lack of a reset command in NVidia cards?

I'm fine with hardware lock to each VM as they are used although I'm not sure how this would work with windows from different VMs displaying simultaneously.

On Mar 7, 2013 7:36 PM, "Cosmic Charade" <cosmic...@gmail.com> wrote:

On Thursday, 7 March 2013 17:50:10 UTC+11, Radosław Szkodziński wrote:

You can redirect the GPU only to one virtual machine at a time. The
real question is whether the driver correctly resets the card, so you
can attach it again.

Works for me..  So I just install the binary drivers in to each VM environment and I'm good to go.

 

For example Catalyst drivers did not (10.12 or so - first version with
Radeon 7950 support) - but xm's old way of reset worked well. Perhaps
someone should patch that into xl as well for cards w/o FLR like that
one.

And here's the catch :-)  Only one way to find out I suppose.

 

Theoretically Qubes GUId may be just about fast enough for full screen
video, if your CPU is fast enough to decode it in software with some
remaining power, as the GUI protocol is relatively CPU intensive.

Qubes GUID?  You mean the X server and the like in the Fedora VM's or by the hypervisor itself?  Ideally software decoding would be shunted to hardware wherever possible as most PC's have this sort of hardware built in now (decode acceleration), but even so the binary driver run everything just fine I would have thought.

 

It is too slow for fullscreen Flash though - that thing has very slow
software decoding and/or scaling.
(CPU here: Xeon E3 1275)

Should be fine with binary drivers, I'll find out.

 

--
Radosław Szkodziński

On Fri, Mar 8, 2013 at 8:49 AM, bradbury9 <ray.br...@gmail.com> wrote:
> On the links I provided there was a guy that workarounded that problem
> configuring the HVM to not to reset the device, but I share Radoslaw
> opinion. It would be wiser to patch the code. Is vmware code publicy
> accesible? they do two different alternative ways to reset if FLR is not
> available.

PCI bus reset sounds a bit harsh? Could that damage hardware in any way?

On Fri, Mar 8, 2013 at 9:45 PM, Cosmic Charade <cosmic...@gmail.com> wrote:
> PCI bus reset sounds a bit harsh? Could that damage hardware in any way?

So it is a harsh method but could work then... may need a way to soft restart PC if it hangs then

Xend has the right reset code, tries: FLR, then P-states warm reset,
then P-states power off, and if all fails, PCI bus reset.
This is obviously available.

--
Radosław Szkodziński

Has anyone managed to completely pass any graphics card to a HVM in qubes yet? Or has this thread firmly settled on not-possible-right-now?

— 

I'm building a PC and would like to use Qubes. Since this means getting components that play nice with VT-d anyway, it seems a shame not to at least try GPU passthrough rather than perpetual system swapping. To this end I am considering getting an intel processor with onboard graphics for Qubes, and an ATI card (R9 280X) to passthrough to a Win8 HVM (with another monitor connection to the card). 

Right now, I have zero experience with qubes (this will be remedied!), but reasons I think this isn't just a mad wish:

• Xen wiki about Xen 4.1.1: "Passing thru AMD/ATI Radeon/FirePro/FireGL adapters as secondary to the VM should work out-of-the-box (you need latest ATI gfx drivers in the VM). Secondary means the Xen Qemu-dm virtual Cirrus adapter is the primary where you see the VM BIOS etc when powering on the VM, and the passthru adapter is secondary, so you can enable/use it after the OS in the VM has started and you've installed drivers for the adapter."
• A xen user's success story / tutorial with a "7970/R9 280X" with Ubuntu and Windows 7. 
• Everyone reporting a failures seems to be talking about nvidia GPUs, which are known to misbehave under xen for a number of reasons.

Does that leave any reason why these settings shouldn't work in qubes? Of course, qubes isn't just xen, so I imagine the differences are where the trouble lies, but I don’t yet know where all the differences lie.

Security-wise, again I understand that I understand basically nothing, but from Joanna’s reply above, it seems to me that there isn’t too much danger as long as I never assign the GPU to any higher security areas.

Something I found on xen forum about how to determine if FLR function exists on your devices. So my question is does your Radeon 7950 support FLR and if not how did you manage to reset  using xm and not xl, manually ? my current set up is  t420s with  Integrated graphics  [intel hd graphics 3000 ( which is basically integrated graphics on cpu)] I7-2620m then on top of this there exists on the mother board also a Nvidia NVS 4200M. Which I want to pass through to my windows 7 vm so I can fully utilize this for gaming. what do you guys think ? before doing a format on this windows system I would like to know your opinion.

How can I check if PCI device supports FLR (Function Level Reset)?

Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in the
DevCap field.

If you are Ubuntu/Debian user don't forget to add sudo at front,
otherwise,
you won't get the result you should get.

sudo lspci -vv | egrep -i --colour flreset

The above line should get root access for lspci program and show color
with
flreset it found from output If you see output with "FLReset-" then your PCI device don't support FLR function. If output has "FLReset+" then it does.

On 09/27/14 09:50, Radoslaw Szkodzinski wrote:
> 7950 does not support FLR. However, the card reacts well to PCI reset,
> as used to be done by xm - returns to a fully clean state.
> (In linux, you will need to reload the drivers for it to work again -
> the firmware has to be reuploaded.)
>
> xl depends (or depended?) on the guest OS to reset the card,

> On 09/27/14 09:50, Radoslaw Szkodzinski wrote:
>> 7950 does not support FLR. However, the card reacts well to PCI reset,
>> as used to be done by xm - returns to a fully clean state.
>> (In linux, you will need to reload the drivers for it to work again -
>> the firmware has to be reuploaded.)
>>
>> xl depends (or depended?) on the guest OS to reset the card,

On 09/27/14 10:42, Joanna Rutkowska wrote:
> Where do you get this info from?

So with my above mentioned set up do you think that I will be able to pass the NVS 4200M to the windows 7 vm and since it does not support FLR what do you recommend so I am able to utilize this fully in the vm ? I am new to linux and all, my current set up is win7 with truecrypt, boot loader on thumb drive. with AES hardware encryption on i7 and bios tpm fingerprint. But I see that the future is in hypervisor's so I want to migrate to such a platform. I bought the t420s soly' on the fact that it was listed in the Qubes os supported hardware. So I would like to utilize this new system much as I can, preferably not to dual boot for gaming, would be defeating the purpose of a hypervisor.

On Sat, Sep 27, 2014 at 12:23 PM, guyfawkes <guyfaw...@yandex.ru> wrote:
> So with my above mentioned set up do you think that I will be able to pass
> the NVS 4200M to the windows 7 vm and since it does not support FLR what do
> you recommend so I am able to utilize this fully in the vm ? I am new to
> linux and all, my current set up is win7 with truecrypt, boot loader on
> thumb drive. with AES hardware encryption on i7 and bios tpm fingerprint.
> But I see that the future is in hypervisor's so I want to migrate to such a
> platform. I bought the t420s soly' on the fact that it was listed in the
> Qubes os supported hardware. So I would like to utilize this new system much
> as I can, preferably not to dual boot for gaming, would be defeating the
> purpose of a hypervisor.

> On Saturday, September 27, 2014 3:52:35 AM UTC-5, joanna wrote:
>>
>> > On 09/27/14 09:50, Radoslaw Szkodzinski wrote:
>> >> 7950 does not support FLR. However, the card reacts well to PCI reset,
>> >> as used to be done by xm - returns to a fully clean state.
>> >> (In linux, you will need to reload the drivers for it to work again -
>> >> the firmware has to be reuploaded.)
>> >>
>> >> xl depends (or depended?) on the guest OS to reset the card,
>>
>> On 09/27/14 10:42, Joanna Rutkowska wrote:
>> > Where do you get this info from?
>>
>> On 09/27/14 10:46, Radoslaw Szkodzinski wrote:
>> > Got it a long time ago from Konrad when I asked what is the difference
>> > - why xl didn't work and xm did.
>> > Not sure it's still accurate though.
>> >
>>
>> That would be totally wrong, as the guest is normally untrusted. If you
>> cannot point out to specific code to support your statements, and/or are
>> unsure about what you're talking about, please do not make them sound
>> authoritative.
>>
>> And, please, don't remove quoted text, it's useful for referenced. Not
>> everybody is reading this via Google groups Web interface.
>>
>> joanna.
>>

On 09/27/14 10:10, guyfaw...@yandex.ru wrote:
> So with my above mentioned set up do you think that I will be able to pass

> do you recommend so I am able to utilize this fully in the vm ? I am new to
> linux and all, my current set up is win7 with truecrypt, boot loader on
> thumb drive. with AES hardware encryption on i7 and bios tpm fingerprint.
> But I see that the future is in hypervisor's so I want to migrate to such a
> platform. I bought the t420s soly' on the fact that it was listed in the
> Qubes os supported hardware. So I would like to utilize this new system
> much as I can, preferably not to dual boot for gaming, would be defeating

On Sat, Sep 27, 2014 at 3:15 PM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:
> On 09/27/14 14:51, Radoslaw Szkodzinski wrote:
>> On Sat, Sep 27, 2014 at 12:23 PM, guyfawkes <guyfaw...@yandex.ru> wrote:
>>> So with my above mentioned set up do you think that I will be able to pass
>>> the NVS 4200M to the windows 7 vm and since it does not support FLR what do
>>> you recommend so I am able to utilize this fully in the vm ? I am new to
>>> linux and all, my current set up is win7 with truecrypt, boot loader on
>>> thumb drive. with AES hardware encryption on i7 and bios tpm fingerprint.
>>> But I see that the future is in hypervisor's so I want to migrate to such a
>>> platform. I bought the t420s soly' on the fact that it was listed in the
>>> Qubes os supported hardware. So I would like to utilize this new system much
>>> as I can, preferably not to dual boot for gaming, would be defeating the
>>> purpose of a hypervisor.
>>
>> It should work with new Xen. I'm not sure which version is in Qubes R3
>> alpha though, probably still too old.
>>
>>> On Saturday, September 27, 2014 3:52:35 AM UTC-5, joanna wrote:

> Xen has been using PCI bus reset as part of do_FLR() since at least 3.x
> (was doing that in case the device didn't support FLR). Please back up
> your claims with specific code refs, or stop spreading misinformation.