Re: [Xen-devel] Failed to access register with invalid access size alignment

["Zytaruk, Kelly" <Kelly.Zytaruk@xxxxxxx>]

> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> Sent: Thursday, April 10, 2014 10:15 AM
> To: Zytaruk, Kelly
> Cc: Jan Beulich; Xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Failed to access register with invalid access size
> alignment
> 
> On 10/04/14 15:06, Zytaruk, Kelly wrote:
> >
> >> -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: Wednesday, April 09, 2014 11:40 AM
> >> To: Zytaruk, Kelly
> >> Cc: Xen-devel@xxxxxxxxxxxxx
> >> Subject: RE: [Xen-devel] Failed to access register with invalid
> >> access size alignment
> >>
> >>>>> On 09.04.14 at 17:32, <Kelly.Zytaruk@xxxxxxx> wrote:
> >>>>> Did you manage to find out where the bad request originates, and
> >>>>> how it behaves when run on bare hardware?
> >>> Using Xenctx (thanks Konrad ) I have managed to determine that the
> >>> access is coming from a call to "hal!READ_PORT_ULONG" in the Win7
> >>> guest.  This is the guest OS that is making the request.
> >> Which, I'm afraid, means that we'll have to allow the access in one
> >> way or another (up to and including the current model, as I then
> >> would conclude this isn't causing any actual problem - iirc you
> >> merely tried to understand whether it would).
> >>
> > In this specific case it doesn't appear to be the root of my problem (back 
> > to the
> drawing board).  I am passing through two PCI devices; a graphics adapter and 
> a
> 1394 firewire adapter.  It only does the mis-aligned access for the graphics
> adapter.  The 1394 appears not to have any problem.
> >
> > This is happening long before the graphics driver is loaded in the guest.  
> > In this
> specific case it does not cause as issue (assuming that it is relying only the
> header type).  For the case of the graphics adapter the header type is '0' 
> which is
> the default that QEMU returns when it sees the invalid alignment access, so no
> problem here.  If however the alignment problem occurred with a type 1 header
> then there would be a problem.  But I really don't know what is causing Win7 
> to
> treat the graphics adapter differently so it is hard to say whether or not 
> this
> would occur under different scenarios.
> >
> > Kelly
> 
> What is the class code of the graphics adapter, and which virtual display is 
> qemu
> creating for the domain?

I have 2 graphics cards that I am testing with (one at a time, not both in the 
same system at the same time).  Both of them return a class code of 0x0300.  
Both of them display the mis-aligned access to offset 0x0e. 

My test configuration/scenario is as follows;
- Primary adapter is AMD APU. (ie Xen boot to APU)
- Secondary adapter is one of the cards mentioned above.
- Pass through one of the test cards as a secondary to the guest
- Connect to guest with 'xl vncviewer <domId>'

Results for each card:
- In both cases I see the Windows 7 splash display in the VNC session.
- In both cases I get an error in the log file about the unaligned access to 
0x0e

- On one card 
        In the VNC session I get to the Windows logon prompt. I can logon to 
windows and Cirrus is the active display.  I see in Device Manager of the guest 
Win7 that the real graphics adapter has stopped working.  This led me to look 
into the log file and started suspecting the unaligned access.  After much 
testing and debugging I grabbed the second graphics adapter and tested with it.

- On the second adapter
        In the VNC session I don't see anything after the Win7 splash screen, 
it "freezes" on the splash screen.  A display attached to the passed through 
adapter lights up and I see the logon prompt on the display.  I can move my 
mouse in the VNC session and it moves on the physical display.  In the Device 
Manager of the Win 7 guest I see that the driver is loaded for the physical 
passed through adapter and the Cirrus driver is "banged-out".



> 
> We have seen issues with cards in the past where the class code was "Other".
> Win7 saw an emulated cirrus display, decided it was the most capable real
> display adapter, loaded its legacy graphics driver stack and was unable to
> subsequently load the non-legacy driver for the "Other" card.

Yes, I have seen this issue as well with Gemini cards and I am working on a fix 
for it, but that is a discussion for a separate thread.  I have it working for 
QEMU-traditional but it doesn't work with QEMU-upstream.

> 
> ~Andrew

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