Status IGD pass-through with QEMU/KVM

Status IGD pass-through with QEMU/KVM

[Jan Kiszka]

Hi Alex,

before getting dirty fingers in vain: what is the current status of
handing an IGD GPU to a KVM guest, specifically Windows? I found some
related QEMU patches from last year on the list, but it seems they
didn't progress. Are there open issues without known solutions or is it
"just" about putting pieces together - given that there related patches
for Xen floating around?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

[Qemu-devel] Status IGD pass-through with QEMU/KVM

[Jan Kiszka]

Hi Alex,

before getting dirty fingers in vain: what is the current status of
handing an IGD GPU to a KVM guest, specifically Windows? I found some
related QEMU patches from last year on the list, but it seems they
didn't progress. Are there open issues without known solutions or is it
"just" about putting pieces together - given that there related patches
for Xen floating around?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: Status IGD pass-through with QEMU/KVM

[Alex Williamson]

On Wed, 2015-01-28 at 16:02 +0100, Jan Kiszka wrote:
> Hi Alex,
> 
> before getting dirty fingers in vain: what is the current status of
> handing an IGD GPU to a KVM guest, specifically Windows? I found some
> related QEMU patches from last year on the list, but it seems they
> didn't progress. Are there open issues without known solutions or is it
> "just" about putting pieces together - given that there related patches
> for Xen floating around?

Hi Jan,

The patches submitted last year by Andrew Barnes are functional (AFAIK),
but mostly proof-of-concept quality.  They make use of /dev/mem in place
of designing VFIO interfaces, they hack into various chipset code, etc.
Based on the attempts to port the Xen IGD code into QEMU, I think Intel
was working on reducing the machine level impact of IGD assignment with
a "universal" driver, but I haven't seen any status updates on that for
some time.  If Intel is successful in creating such a driver, then IGD
assignment may be no more complicated that discrete assignment (but
might only support very new HW).  To support current hardware and
drivers, we need to expose not only the IGD device, but manipulate
chispet device IDs and punch through registers and opregions on other
devices.  Andrew's patches do this, but need help to architect
interfaces and break down the code into upstream-able chunks.  Thanks,

Alex

Re: [Qemu-devel] Status IGD pass-through with QEMU/KVM

[Alex Williamson]

On Wed, 2015-01-28 at 16:02 +0100, Jan Kiszka wrote:
> Hi Alex,
> 
> before getting dirty fingers in vain: what is the current status of
> handing an IGD GPU to a KVM guest, specifically Windows? I found some
> related QEMU patches from last year on the list, but it seems they
> didn't progress. Are there open issues without known solutions or is it
> "just" about putting pieces together - given that there related patches
> for Xen floating around?

Hi Jan,

The patches submitted last year by Andrew Barnes are functional (AFAIK),
but mostly proof-of-concept quality.  They make use of /dev/mem in place
of designing VFIO interfaces, they hack into various chipset code, etc.
Based on the attempts to port the Xen IGD code into QEMU, I think Intel
was working on reducing the machine level impact of IGD assignment with
a "universal" driver, but I haven't seen any status updates on that for
some time.  If Intel is successful in creating such a driver, then IGD
assignment may be no more complicated that discrete assignment (but
might only support very new HW).  To support current hardware and
drivers, we need to expose not only the IGD device, but manipulate
chispet device IDs and punch through registers and opregions on other
devices.  Andrew's patches do this, but need help to architect
interfaces and break down the code into upstream-able chunks.  Thanks,

Alex

Re: Status IGD pass-through with QEMU/KVM

[Jan Kiszka]

On 2015-01-28 16:36, Alex Williamson wrote:
> On Wed, 2015-01-28 at 16:02 +0100, Jan Kiszka wrote:
>> Hi Alex,
>>
>> before getting dirty fingers in vain: what is the current status of
>> handing an IGD GPU to a KVM guest, specifically Windows? I found some
>> related QEMU patches from last year on the list, but it seems they
>> didn't progress. Are there open issues without known solutions or is it
>> "just" about putting pieces together - given that there related patches
>> for Xen floating around?
> 
> Hi Jan,
> 
> The patches submitted last year by Andrew Barnes are functional (AFAIK),
> but mostly proof-of-concept quality.  They make use of /dev/mem in place
> of designing VFIO interfaces, they hack into various chipset code, etc.
> Based on the attempts to port the Xen IGD code into QEMU, I think Intel
> was working on reducing the machine level impact of IGD assignment with
> a "universal" driver, but I haven't seen any status updates on that for
> some time.  If Intel is successful in creating such a driver, then IGD
> assignment may be no more complicated that discrete assignment (but
> might only support very new HW).  To support current hardware and
> drivers, we need to expose not only the IGD device, but manipulate
> chispet device IDs and punch through registers and opregions on other
> devices.  Andrew's patches do this, but need help to architect
> interfaces and break down the code into upstream-able chunks.  Thanks,

OK, thanks. Need to study more details then.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Status IGD pass-through with QEMU/KVM

[Jan Kiszka]

On 2015-01-28 16:36, Alex Williamson wrote:
> On Wed, 2015-01-28 at 16:02 +0100, Jan Kiszka wrote:
>> Hi Alex,
>>
>> before getting dirty fingers in vain: what is the current status of
>> handing an IGD GPU to a KVM guest, specifically Windows? I found some
>> related QEMU patches from last year on the list, but it seems they
>> didn't progress. Are there open issues without known solutions or is it
>> "just" about putting pieces together - given that there related patches
>> for Xen floating around?
> 
> Hi Jan,
> 
> The patches submitted last year by Andrew Barnes are functional (AFAIK),
> but mostly proof-of-concept quality.  They make use of /dev/mem in place
> of designing VFIO interfaces, they hack into various chipset code, etc.
> Based on the attempts to port the Xen IGD code into QEMU, I think Intel
> was working on reducing the machine level impact of IGD assignment with
> a "universal" driver, but I haven't seen any status updates on that for
> some time.  If Intel is successful in creating such a driver, then IGD
> assignment may be no more complicated that discrete assignment (but
> might only support very new HW).  To support current hardware and
> drivers, we need to expose not only the IGD device, but manipulate
> chispet device IDs and punch through registers and opregions on other
> devices.  Andrew's patches do this, but need help to architect
> interfaces and break down the code into upstream-able chunks.  Thanks,

OK, thanks. Need to study more details then.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: Status IGD pass-through with QEMU/KVM

[Jan Kiszka]

On 2015-01-28 16:43, Jan Kiszka wrote:
> On 2015-01-28 16:36, Alex Williamson wrote:
>> On Wed, 2015-01-28 at 16:02 +0100, Jan Kiszka wrote:
>>> Hi Alex,
>>>
>>> before getting dirty fingers in vain: what is the current status of
>>> handing an IGD GPU to a KVM guest, specifically Windows? I found some
>>> related QEMU patches from last year on the list, but it seems they
>>> didn't progress. Are there open issues without known solutions or is it
>>> "just" about putting pieces together - given that there related patches
>>> for Xen floating around?
>>
>> Hi Jan,
>>
>> The patches submitted last year by Andrew Barnes are functional (AFAIK),
>> but mostly proof-of-concept quality.  They make use of /dev/mem in place
>> of designing VFIO interfaces, they hack into various chipset code, etc.
>> Based on the attempts to port the Xen IGD code into QEMU, I think Intel
>> was working on reducing the machine level impact of IGD assignment with
>> a "universal" driver, but I haven't seen any status updates on that for
>> some time.  If Intel is successful in creating such a driver, then IGD
>> assignment may be no more complicated that discrete assignment (but
>> might only support very new HW).  To support current hardware and
>> drivers, we need to expose not only the IGD device, but manipulate
>> chispet device IDs and punch through registers and opregions on other
>> devices.  Andrew's patches do this, but need help to architect
>> interfaces and break down the code into upstream-able chunks.  Thanks,
> 
> OK, thanks. Need to study more details then.

Did so by now, with rather unsatisfying results:

I tried to reproduce the setup Andrew once described, including
identical kernel and seabios. However, starting a guest on a H87I-PLUS
Asus board didn't get me far. The screen remained black, the guest
seemed stuck in the BIOS (didn't check where exactly). I'm either
missing a step or the hacks are still too fragile and break on my setup.

In contrast, running Xen 4.4.1, as it falls out of an OpenSUSE 13.2
installation, on the very same board provided direct success. Linux and
Windows were able to use the GPU, early VGA output included. On Windows
I was able to install the Asus-provided Intel drivers flawlessly (didn't
try i915 under Linux intensively, just the framebuffer console).

Any ideas what could be still a problem? Also CC'ing Andrew - any news
on your side?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Status IGD pass-through with QEMU/KVM

[Jan Kiszka]

On 2015-01-28 16:43, Jan Kiszka wrote:
> On 2015-01-28 16:36, Alex Williamson wrote:
>> On Wed, 2015-01-28 at 16:02 +0100, Jan Kiszka wrote:
>>> Hi Alex,
>>>
>>> before getting dirty fingers in vain: what is the current status of
>>> handing an IGD GPU to a KVM guest, specifically Windows? I found some
>>> related QEMU patches from last year on the list, but it seems they
>>> didn't progress. Are there open issues without known solutions or is it
>>> "just" about putting pieces together - given that there related patches
>>> for Xen floating around?
>>
>> Hi Jan,
>>
>> The patches submitted last year by Andrew Barnes are functional (AFAIK),
>> but mostly proof-of-concept quality.  They make use of /dev/mem in place
>> of designing VFIO interfaces, they hack into various chipset code, etc.
>> Based on the attempts to port the Xen IGD code into QEMU, I think Intel
>> was working on reducing the machine level impact of IGD assignment with
>> a "universal" driver, but I haven't seen any status updates on that for
>> some time.  If Intel is successful in creating such a driver, then IGD
>> assignment may be no more complicated that discrete assignment (but
>> might only support very new HW).  To support current hardware and
>> drivers, we need to expose not only the IGD device, but manipulate
>> chispet device IDs and punch through registers and opregions on other
>> devices.  Andrew's patches do this, but need help to architect
>> interfaces and break down the code into upstream-able chunks.  Thanks,
> 
> OK, thanks. Need to study more details then.

Did so by now, with rather unsatisfying results:

I tried to reproduce the setup Andrew once described, including
identical kernel and seabios. However, starting a guest on a H87I-PLUS
Asus board didn't get me far. The screen remained black, the guest
seemed stuck in the BIOS (didn't check where exactly). I'm either
missing a step or the hacks are still too fragile and break on my setup.

In contrast, running Xen 4.4.1, as it falls out of an OpenSUSE 13.2
installation, on the very same board provided direct success. Linux and
Windows were able to use the GPU, early VGA output included. On Windows
I was able to install the Asus-provided Intel drivers flawlessly (didn't
try i915 under Linux intensively, just the framebuffer console).

Any ideas what could be still a problem? Also CC'ing Andrew - any news
on your side?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux