Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initialization

[Oleksii Kurochko]

Hello Greg,

Thanks for answer.

I am trying that you advice me.
Seems that there is same results.

Currently I am stopped this task, but if someone have more ideas why it can
be write please, Ill check.

Btw, I tried to look at /sys/kernel/debug/vgt/irqinfo and here seems all is
fine:

> --
>
> Interrupt control
> status:
> vGT: VLVDEISR is 10, VLVDEIIR is 0, VLVDEIMR is fffdff7f, VLVDEIER is
> 200f0
> vGT: DEISR is 0, DEIIR is 0, DEIMR is 0, DEIER is
> 8000
> vGT: SDEISR is 0, SDEIIR is 0, SDEIMR is 0, SDEIER is
> 0
> vGT: GTISR is 0, GTIIR is 0, GTIMR is 41, GTIER is
> 401001
> vGT: PMISR is 0, PMIIR is 0, PMIMR is 0, PMIER is
> 70
> vGT: RCS_IMR is , VCS_IMR is ffe00fff, BCS_IMR is
> 
> Total 207574 interrupts
> logged:
> #   WARNING: precisely this is the number of
> vGT
> #   physical interrupt handler be
> called,
> #   each calling several events can
> be
> #   been handled, so usually this
> number
> #   is less than the total events
> number.
> 4042: Render Command Streamer MI USER
> INTERRUPT
>1: Render MMIO sync flush
> status
>1: Video MMIO sync flush
> status
>  426: Blitter Command Streamer MI USER
> INTERRUPT
>1: Billter MMIO sync flush
> status
>   202447: Pipe A
> vblank
>38975: Render geyserville UP evaluation interval
> interrupt
> 1987: RP UP threshold
> interrupt
>   21: Render Frequency Downward Timeout During RC6
> interrupt
>   11740980876912: Last
> pirq
>   11740981018263: Last
> virq
>78066: Average pirq
> cycles
>15262: Average virq
> cycles
>   228105: Average delay between pirq/virq
> handling
>
>
> -->vgt-0:
>
> vreg (gtlc_mir: 8000, vlvier: 200f0, vlviir: 0, vlvimr: fffdff2f,
> vlvis)
> vreg (gtier: 401001, gtiir: 0, gtimr: 41, gtisr:
> 0)
> vreg (sdeier: 0, sdeiir: 0, sdeimr: 0, sdeisr:
> 0)
> vreg (pmier: 70, pmiir: 0, pmimr: 0, pmisr:
> 0)
> vreg (rcs_imr: , vcs_imr: 0, bcs_imr:
> 
>   11740981028847: Last
> injection
> Total 208373 virtual irq
> injection:
> 3399: Render Command Streamer MI USER
> INTERRUPT
>1: Render MMIO sync flush
> status
>1: Video MMIO sync flush
> status
>  405: Blitter Command Streamer MI USER
> INTERRUPT
>1: Billter MMIO sync flush
> status
>   202205: Pipe A
> vblank
> 2304: Primary Plane A flip
> done
>38642: Render geyserville UP evaluation interval
> interrupt
> 1737: RP UP threshold
> interrupt
>   21: Render Frequency Downward Timeout During RC6
> interrupt
>
>
> -->vgt-1:
>
> vreg (gtlc_mir: 8000, vlvier: 0, vlviir: 0, vlvimr: ,
> vlvisr: 0)
> vreg (gtier: 401001, gtiir: 0, gtimr: 41, gtisr:
> 0)
> vreg (sdeier: 0, sdeiir: 0, sdeimr: 0, sdeisr:
> 0)
> vreg (pmier: 0, pmiir: 0, pmimr: 0, pmisr:
> 0)
> vreg (rcs_imr: , vcs_imr: 0, bcs_imr:
> 
>9054347637006: Last
> injection
> Total 259251 virtual irq
> injection:
> 3359: Render Command Streamer MI USER
> INTERRUPT
>1: Render MMIO sync flush
> status
>1: Video MMIO sync flush
> status
>  174: Blitter Command Streamer MI USER
> INTERRUPT
>1: Billter MMIO sync flush
> status
>   391176: Pipe A
> vblank
> 3604: Primary Plane A flip
> done
>

With best regards,
 Oleksii



On Thu, Jan 21, 2016 at 8:56 PM, Dr. Greg Wettstein 
wrote:

> On Jan 5, 10:04am, Oleksii Kurochko wrote:
> } Subject: Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure
> initial
>
> > Hey.
>
> Hi Oleksii, I hope this note finds your day going well.
>
> > Strange for me was that I got vmid=0 and gen_type=0, so I decided go
> > to i915_gem_vgtbuffer_ioctl and write next at the start: if
> > (!xen_initial_domain()) { return -EPERM; } Also same code is in 3.17
> > kernel from XenGT-kernel repo.
> >
> > it seems that there is no more this error now( from vgt_fb_decoder ), BUT
> > there is often freeze or very laggy UI in guest.
> >
> > What it can be?
>
> It wasn't in this e-mail but I went through the console logs which
> were in one of your postings on the IGVT-g list.  I believe you have
> your hypervisor configured for synchronous serial console output
> (sync_console command-line parameter) and you are directing your dom0
> kernel console logging through the Xen provided serial interface.
>
> Setting this option is documented to cause significant latencies.  In
> fact there is a warning about this in the Xen console logs when the
> hypervisor boots.  Here is the 

Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initialization

[Dr. Greg Wettstein]

On Jan 5, 10:04am, Oleksii Kurochko wrote:
} Subject: Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initial

> Hey.

Hi Oleksii, I hope this note finds your day going well.

> Strange for me was that I got vmid=0 and gen_type=0, so I decided go
> to i915_gem_vgtbuffer_ioctl and write next at the start: if
> (!xen_initial_domain()) { return -EPERM; } Also same code is in 3.17
> kernel from XenGT-kernel repo.
>
> it seems that there is no more this error now( from vgt_fb_decoder ), BUT
> there is often freeze or very laggy UI in guest.
> 
> What it can be?

It wasn't in this e-mail but I went through the console logs which
were in one of your postings on the IGVT-g list.  I believe you have
your hypervisor configured for synchronous serial console output
(sync_console command-line parameter) and you are directing your dom0
kernel console logging through the Xen provided serial interface.

Setting this option is documented to cause significant latencies.  In
fact there is a warning about this in the Xen console logs when the
hypervisor boots.  Here is the code snippet from
 xen/drivers/char/console.c:console_endboot() which produces the
message:

if ( opt_sync_console )
{
printk("**\n");
printk("*** WARNING: CONSOLE OUTPUT IS SYNCHRONOUS\n");
printk("*** This option is intended to aid debugging "
   "of Xen by ensuring\n");
printk("*** that all output is synchronously delivered "
   "on the serial line.\n");
printk("*** However it can introduce SIGNIFICANT latencies "
   "and affect\n");
printk("*** timekeeping. It is NOT recommended for "
   "production use!\n");
printk("**\n");


It appears as if you were generating significant amounts of kernel log
output which may be at the root of the unacceptable latencies.  I
would start by turning off that option and see if your guest
performance improves.

> With best regards,
>  Oleksii

Good luck with your work.

Greg

}-- End of excerpt from Oleksii Kurochko

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.   Specializing in information infra-structure
Fargo, ND  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com
--
"Sweeny's Law: The length of a progress report is inversely proportional
 to the amount of progress."

-- 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initialization

[Oleksii Kurochko]

Hello.

Looks you didn’t set IRQ_INFO_GT for BCS event. Is it a typo?
>
Yeap, it was typo.

I will look at debug inforamtion that U told.

Thanks.

On Thu, Jan 14, 2016 at 7:44 AM, Tian, Kevin  wrote:

> if (IS_VLV(pdev)) {
>
>  SET_BIT_INFO(hstate, 2, RCS_MMIO_SYNC_FLUSH, IRQ_INFO_GT);
>
>  SET_BIT_INFO(hstate, 14, VCS_MMIO_SYNC_FLUSH, IRQ_INFO_GT);
>
>  SET_BIT_INFO(hstate, 24, BCS_MMIO_SYNC_FLUSH);
> }
>
>
>
> Looks you didn’t set IRQ_INFO_GT for BCS event. Is it a typo?
>
>
>
> Generally you can look at /sys/kernel/debug/vgt/irqinfo to see virtual
> event injection status, which may give some hint.
>
>
>
> In your log there is hangcheck triggered in Dom0:
>
> [   51.521359] vGT info:(vgt_handle_dom0_device_reset:940) DOM0 hangcheck
> timer request reset device.
>
> It means GPU is already hung.
>
>
>
> I don’t have an immediate idea now since this is only an experimental code
> and not sure how much your hardware is different from its assume
> configuration.
>
>
>
> A simpler case might be to just run some 3D workloads within Dom0 to see
> whether it works well, and then try launch another guest later.
>
>
>
> Thanks
>
> Kevin
>



-- 
Oleksii Kurochko | Embedded Dev
GlobalLogic
www.globallogic.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initialization

[Tian, Kevin]

if (IS_VLV(pdev)) {
 SET_BIT_INFO(hstate, 2, RCS_MMIO_SYNC_FLUSH, IRQ_INFO_GT);
 SET_BIT_INFO(hstate, 14, VCS_MMIO_SYNC_FLUSH, IRQ_INFO_GT);
 SET_BIT_INFO(hstate, 24, BCS_MMIO_SYNC_FLUSH);
}

Looks you didn’t set IRQ_INFO_GT for BCS event. Is it a typo?

Generally you can look at /sys/kernel/debug/vgt/irqinfo to see virtual event 
injection status, which may give some hint.

In your log there is hangcheck triggered in Dom0:
[   51.521359] vGT info:(vgt_handle_dom0_device_reset:940) DOM0 hangcheck timer 
request reset device.

It means GPU is already hung.

I don’t have an immediate idea now since this is only an experimental code and 
not sure how much your hardware is different from its assume configuration.

A simpler case might be to just run some 3D workloads within Dom0 to see 
whether it works well, and then try launch another guest later.

Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initialization

[Oleksii Kurochko]

Hello.

I tried to fix next error message:
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initialization

[Tian, Kevin]

Did you install some specific agent within VM to utilize vgtbuffer ioctl 
interface? It’s not a bare metal i915 interface so suppose it shouldn’t be 
invoked for a default Linux distro environment. Yes we should add check to 
prevent it from being used within VM.

However this error has nothing to do with your laggy UI issue. From my 
experience such issue is most likely being caused by losing interrupts. For 
example I saw below error message in your log (only partial line):

[ 5412.902817] vGT error:(vgt_handle_events:1845) IRQ: abandon non-registered [)

You can look into the event detail to see whether such event should be 
explicitly handled on your platform.

Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initialization

[Oleksii Kurochko]

Hello.

Thanks for answer.

About what agent are u talking about? I did not install anything
additional, just took vgt kernel and used it for Ubuntu distro.

I will look in events, thanks.

With the best regards,
Oleksii

On Mon, 11 Jan 2016, 07:07 Tian, Kevin  wrote:

> Did you install some specific agent within VM to utilize vgtbuffer ioctl
> interface? It’s not a bare metal i915 interface so suppose it shouldn’t be
> invoked for a default Linux distro environment. Yes we should add check to
> prevent it from being used within VM.
>
>
>
> However this error has nothing to do with your laggy UI issue. From my
> experience such issue is most likely being caused by losing interrupts. For
> example I saw below error message in your log (only partial line):
>
>
>
> [ 5412.902817] vGT error:(vgt_handle_events:1845) IRQ: abandon
> non-registered [)
>
> You can look into the event detail to see whether such event should be
> explicitly handled on your platform.
>
>
>
> Thanks
>
> Kevin
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initialization

[Tian, Kevin]

I don’t know exact agent. As I said, vgtbuffer ioctl interface is used only by 
new application which wants to composite guest framebuffer. There is no 
existing application from standard Linux distro using it. So that’s why I’m 
curious whether you installed something within VM.

From: Oleksii Kurochko [mailto:oleksii.kuroc...@globallogic.com]
Sent: Monday, January 11, 2016 1:44 PM
To: Tian, Kevin
Cc: Dong, Eddie; Gerd Hoffmann; Li, Susie; igv...@lists.01.org; 
igv...@ml01.01.org; xen-devel@lists.xen.org
Subject: Re: [XenGT][IGVT-g] DomU pgt_device structure initialization

Hello.

Thanks for answer.

About what agent are u talking about? I did not install anything additional, 
just took vgt kernel and used it for Ubuntu distro.

I will look in events, thanks.

With the best regards,
Oleksii

On Mon, 11 Jan 2016, 07:07 Tian, Kevin 
> wrote:
Did you install some specific agent within VM to utilize vgtbuffer ioctl 
interface? It’s not a bare metal i915 interface so suppose it shouldn’t be 
invoked for a default Linux distro environment. Yes we should add check to 
prevent it from being used within VM.

However this error has nothing to do with your laggy UI issue. From my 
experience such issue is most likely being caused by losing interrupts. For 
example I saw below error message in your log (only partial line):

[ 5412.902817] vGT error:(vgt_handle_events:1845) IRQ: abandon non-registered [)
You can look into the event detail to see whether such event should be 
explicitly handled on your platform.

Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel