How to passthrough graphic device in crosvm?

[Shirley Zhao]

Hello, all, 

How to passthrough the graphic/display device to guest in crosvm? 

We used the following option but failed, --vfio /sys/bus/pci/devices/0000:00:02.0/,iommu=on

Is there anything wrong? Or is there any sample can be referenced? 

Thanks. 

Shirley

[Daniel Verkamp]

Hi Shirley,

Based on the `crosvm run --help` output, I believe the --vfio option
wants a PCI address (e.g. "--vfio 0000:00:02.0,iommu=on" in your case)
rather than a sysfs path.

If this doesn't work, could you also provide logs of the failure?

Thanks,
-- Daniel

[Daniel Verkamp]

On Mon, Sep 12, 2022 at 11:15 AM Daniel Verkamp <dver...@google.com> wrote:
>
> On Wed, Sep 7, 2022 at 7:37 PM Shirley Zhao <shirle...@intel.com> wrote:
> >
> > Hello, all,
> >
> > How to passthrough the graphic/display device to guest in crosvm?
> > We used the following option but failed, --vfio /sys/bus/pci/devices/0000:00:02.0/,iommu=on
> >
> > Is there anything wrong? Or is there any sample can be referenced?
> >
> > Thanks.
> > Shirley
>
> Hi Shirley,
>
> Based on the `crosvm run --help` output, I believe the --vfio option
> wants a PCI address (e.g. "--vfio 0000:00:02.0,iommu=on" in your case)
> rather than a sysfs path.

Sorry, I actually misread the help output (this applies to the
guest-address option, not the first --vfio argument). However, I think
the problem might be the `iommu=on` part - the iommu parameter should
be one of "off", "viommu", or "coiommu".

[David Stevens]

I'd also like to clarify that this iommu argument configures the iommu state of the passthrough device within the guest. The passthrough device will always use the platform IOMMU in the host, regardless of the value of this argument - that's a requirement for the device to be exposed to userspace via VFIO in the first place.

I don't know what your use case is, but here's some information to help decide which mode to use. If the passthrough device is configured to use viommu, then only memory which is actively being used for DMA is pinned. The overhead from doing this is fairly high, but it gives intra-guest protection and allows the virtio-balloon to operate. If you use coiommu, memory is pinned the first time it is used for DMA and then lazily unpinned. This significantly reduces the performance overhead compared to viommu and allows the virtio-balloon to operate, but you lose the intra-guest protection guarantees. Finally, without an iommu in the guest, all guest memory needs to be pinned at startup. This has the lowest runtime overhead, but there's no intra-guest protection and the virtio-balloon won't work.

-David

 

>
> If this doesn't work, could you also provide logs of the failure?
>
> Thanks,
> -- Daniel

--
You received this message because you are subscribed to the Google Groups "crosvm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crosvm-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crosvm-dev/CABVzXAnB-oCnfQ5zx1r%3D0JnwKNvXc8kfizsCO2%2Bmvo4c0%2BQ7Rw%40mail.gmail.com.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Zhao, Shirley]

Hi, David and Daniel,

 

We did further investigation these days, and found for graphic passthrough, it depends on PCH device.

So we added PCH device as:

--stub-pci-device 0000:00:1f.0,vendor=0x8086,device=0x2918,class=0x60100,subsystem_vendor=0x1af4,subsystem_device=0x1100

 

There is no crash now and OS can be booted up into kernel, but display can’t work normally.

After debug, we found there shorts lots of Device configure or FW configure.

For example,  in Intel graphic driver, there is no engine found, like below.

 

unsigned int intel_engines_has_context_isolation(struct drm_i915_private *i915)

{

                struct intel_engine_cs *engine;

                unsigned int which;

 

                which = 0;

                for_each_uabi_engine(engine, i915) {

                                // no engine was found in i915 device here;

                                if (engine->default_state) {

                                                which |= BIT(engine->uabi_class);

                                }

                }

 

                return which;

}

 

In our POC, we want to passthrough graphic device through Crosvm + OVMF + Android.

We think whether it can be solved by transfer the FW configure information from corsvm to OVMF + Android.

 

Do you have any suggestion?

 

Thanks.

• Shirley

--
You received this message because you are subscribed to a topic in the Google Groups "crosvm-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/crosvm-dev/2aQNvVzoLqU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to crosvm-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crosvm-dev/CAOiLmNHAuCciUHuFkQcksLnNpe%2BdiCz-ApFbDGdfZY%3DX9FTg%2Bw%40mail.gmail.com.

[Zhang, Xiong Y]

Hi, Shirley:

1) For i915 driver depended on PCH, I ever fixed through:

a1f6bfe17931 drm/i915: Try to guess PCH type even without ISA bridge

please check whether your android kernel has this commit or not.

 

2) For “there shorts lots of Device configure or FW configure”, did you package iGOP into OVMF ? as vfio-pci and iGOP will do several pci reset to initialize passthrough iGPU, host FW initialized iGPU info may be lost after these pci reset. If you don’t package iGOP into OVMF, the following patch may be helpful.

a. https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2412387

b. pass vfio_pci.disable_function_reset=1 to host kernel

 

thanks

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crosvm-dev/BY5PR11MB429122BD258152ADED823A998D4C9%40BY5PR11MB4291.namprd11.prod.outlook.com.