Failed to access register with invalid access size alignment

Failed to access register with invalid access size alignment

[Zytaruk, Kelly]

I have seen the subject-line error message in a few posts but I haven't yet seen a resolution for it yet.  Has anyone resolved this problem?

The full error line from the log file is;
[00:05.0] xen_pt_pci_config_access_check: Error: Failed to access register with invalid access size alignment. (addr: 0x0e, len: 4)

Address 0x0e in PCIe config space is 2 byte aligned and can't be accessed as a 4 byte read.

I am passing an AMD graphics adapter into a guest as a secondary adapter.  I can connect with VNC and the PCI passthrough is successful as I can see the [00:05.0] device in Win7 device Manager but the device is "banged out" with the error "Windows has stopped this device because it has reported problems. (Code 43)".

The error occurs with both QEMU-upstream and QEMU-traditional.
My configuration is Xen 4.5-unstable on Linux 3.13.4.

Thanks,
Kelly

Re: Failed to access register with invalid access size alignment

[Jan Beulich]

>>> On 02.04.14 at 21:28, <Kelly.Zytaruk@amd.com> wrote:
> I have seen the subject-line error message in a few posts but I haven't yet 
> seen a resolution for it yet.  Has anyone resolved this problem?
> 
> The full error line from the log file is;
> [00:05.0] xen_pt_pci_config_access_check: Error: Failed to access register 
> with invalid access size alignment. (addr: 0x0e, len: 4)
> 
> Address 0x0e in PCIe config space is 2 byte aligned and can't be accessed as 
> a 4 byte read.

And hence one would think that it should be addressed in the guest
OS rather than Xen or qemu. But of course it depends to some degree
on whether real hardware permits the mis-aligned accesses - we may
need to relax the restrictions if so.

Did you manage to find out where the bad request originates, and
how it behaves when run on bare hardware?

Jan

Re: Failed to access register with invalid access size alignment

[Zytaruk, Kelly]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Thursday, April 03, 2014 4:41 AM
> To: Zytaruk, Kelly
> Cc: Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Failed to access register with invalid access size
> alignment
> 
> >>> On 02.04.14 at 21:28, <Kelly.Zytaruk@amd.com> wrote:
> > I have seen the subject-line error message in a few posts but I
> > haven't yet seen a resolution for it yet.  Has anyone resolved this problem?
> >
> > The full error line from the log file is; [00:05.0]
> > xen_pt_pci_config_access_check: Error: Failed to access register with
> > invalid access size alignment. (addr: 0x0e, len: 4)
> >
> > Address 0x0e in PCIe config space is 2 byte aligned and can't be
> > accessed as a 4 byte read.
> 
> And hence one would think that it should be addressed in the guest OS rather
> than Xen or qemu. 

I am seeing the error very early on in the guest VM startup sequence so I suspect that the guest OS doesn't even have control yet.  I haven't spent a lot of time triaging it yet but I suspect it may be coming from the emulated SBios in the guest, I need to do more investigating.  I have Win7 as my guest OS.  I don't see this error when I run Win7 as a guest on Xen 4.2 with QEMU-traditional.  This error shows up with Win7 as a guest on Xen 4.5-unstable.

>But of course it depends to some degree on whether real
> hardware permits the mis-aligned accesses

While some hardware implementations may permit mis-aligned accesses the PCIe spec states that hardware support for mis-aligned accesses is not required.  So we could end up with some hardware supporting it while others do not.  With this in mind I would default to "not-supported".

> - we may need to relax the restrictions if so.

I would prefer to keep the restriction in there in part due to the relaxed PCIe requirement to support it (as stated above).
The other reason I would like to keep it there is because I suspect this to be a coding bug and this would be the best way of exposing bugs.  Just looking at this specific example it is a 4 byte read from address 0x0e.  PCIe config space is defined as;

+--------------------------------+-------------------------+
|             Device Id                  |           Vendor Id          |  0x00
+--------------------------------+-------------------------+
|               Status                      |         Command           |  0x04
+--------------+----------------+--------------------------+
| ClassCode |     Subclass     | Prog I/F |      RevID    |  0x08
+--------------+----------------+-----------+--------------+
|       BIST      | Header Type | Latency | Cache Line |  0x0C
+--------------+----------------+-----------+--------------+
|                                           BAR 0                                    |  0x10
+--------------------------------+--------------------------+
| ...

A 4 byte read from offset 0x0e would return the HeaderType, BIST capability, and half of BAR0.  I don't see any logical reason to be reading half of BAR0.  I suspect that this was supposed to be a single byte read of the header type but somewhere a typo caused it to be a DWORD read instead.


> 
> Did you manage to find out where the bad request originates, and how it
> behaves when run on bare hardware?

I haven't spent enough time on it yet to find out where it originates.  I scanned the archives and noticed that other people have reported seeing the same issue but I didn't see any resolution for it yet.  I don't know if someone figured out what the problem was or if they just gave up.

Is anyone looking into this yet?  If so, I can possibly provide some assistance, if not I may have to hunker-down and attack it myself.   If anyone has any leads on this I would love to hear from you so I don't duplicate effort that has already been spent, or even if someone has an idea as to where to start looking...

> 
> Jan
> 

Re: Failed to access register with invalid access size alignment

[Zytaruk, Kelly]

> >
> > >>> On 02.04.14 at 21:28, <Kelly.Zytaruk@amd.com> wrote:
> > > I have seen the subject-line error message in a few posts but I
> > > haven't yet seen a resolution for it yet.  Has anyone resolved this problem?
> > >
> > > The full error line from the log file is; [00:05.0]
> > > xen_pt_pci_config_access_check: Error: Failed to access register
> > > with invalid access size alignment. (addr: 0x0e, len: 4)
> > >
> > > Address 0x0e in PCIe config space is 2 byte aligned and can't be
> > > accessed as a 4 byte read.
> >
> > And hence one would think that it should be addressed in the guest OS
> > rather than Xen or qemu.
> 
> I am seeing the error very early on in the guest VM startup sequence so I suspect
> that the guest OS doesn't even have control yet.  I haven't spent a lot of time
> triaging it yet but I suspect it may be coming from the emulated SBios in the
> guest, I need to do more investigating.  I have Win7 as my guest OS.  I don't see
> this error when I run Win7 as a guest on Xen 4.2 with QEMU-traditional.  This
> error shows up with Win7 as a guest on Xen 4.5-unstable.
> 
> >But of course it depends to some degree on whether real  hardware
> >permits the mis-aligned accesses
> 
> While some hardware implementations may permit mis-aligned accesses the
> PCIe spec states that hardware support for mis-aligned accesses is not required.
> So we could end up with some hardware supporting it while others do not.  With
> this in mind I would default to "not-supported".
> 
> > - we may need to relax the restrictions if so.
> 

I think this is something that needs further discussion.  I would have preferred not to relax the restriction as it relies on the "good-will" of the hardware platform but I suppose that there is no reason why QEMU couldn't implement "friendly" hardware.

> I would prefer to keep the restriction in there in part due to the relaxed PCIe
> requirement to support it (as stated above).
> The other reason I would like to keep it there is because I suspect this to be a
> coding bug and this would be the best way of exposing bugs.  Just looking at this
> specific example it is a 4 byte read from address 0x0e.  PCIe config space is
> defined as;
> 
> +--------------------------------+-------------------------+
> |             Device Id                  |           Vendor Id          |  0x00
> +--------------------------------+-------------------------+
> |               Status                      |         Command           |  0x04
> +--------------+----------------+--------------------------+
> | ClassCode |     Subclass     | Prog I/F |      RevID    |  0x08
> +--------------+----------------+-----------+--------------+
> |       BIST      | Header Type | Latency | Cache Line |  0x0C
> +--------------+----------------+-----------+--------------+
> |                                           BAR 0                                    |  0x10
> +--------------------------------+--------------------------+
> | ...
> 
> A 4 byte read from offset 0x0e would return the HeaderType, BIST capability,
> and half of BAR0.  I don't see any logical reason to be reading half of BAR0.  I
> suspect that this was supposed to be a single byte read of the header type but
> somewhere a typo caused it to be a DWORD read instead.
> 
> 
> >
> > 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.

> I haven't spent enough time on it yet to find out where it originates.  I scanned
> the archives and noticed that other people have reported seeing the same issue
> but I didn't see any resolution for it yet.  I don't know if someone figured out
> what the problem was or if they just gave up.
> 
> Is anyone looking into this yet?  If so, I can possibly provide some assistance, if
> not I may have to hunker-down and attack it myself.   If anyone has any leads on
> this I would love to hear from you so I don't duplicate effort that has already
> been spent, or even if someone has an idea as to where to start looking...
> 
> >
> > Jan
> >
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Failed to access register with invalid access size alignment

[Jan Beulich]

>>> On 09.04.14 at 17:32, <Kelly.Zytaruk@amd.com> 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).

Jan

Re: Failed to access register with invalid access size alignment

[Zytaruk, Kelly]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, April 09, 2014 11:40 AM
> To: Zytaruk, Kelly
> Cc: Xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] Failed to access register with invalid access size
> alignment
> 
> >>> On 09.04.14 at 17:32, <Kelly.Zytaruk@amd.com> 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

> Jan

Re: Failed to access register with invalid access size alignment

[Andrew Cooper]

On 10/04/14 15:06, Zytaruk, Kelly wrote:
>
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Wednesday, April 09, 2014 11:40 AM
>> To: Zytaruk, Kelly
>> Cc: Xen-devel@lists.xen.org
>> Subject: RE: [Xen-devel] Failed to access register with invalid access size
>> alignment
>>
>>>>> On 09.04.14 at 17:32, <Kelly.Zytaruk@amd.com> 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?

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.

~Andrew

Re: Failed to access register with invalid access size alignment

[Zytaruk, Kelly]

> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> Sent: Thursday, April 10, 2014 10:15 AM
> To: Zytaruk, Kelly
> Cc: Jan Beulich; Xen-devel@lists.xen.org
> 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@suse.com]
> >> Sent: Wednesday, April 09, 2014 11:40 AM
> >> To: Zytaruk, Kelly
> >> Cc: Xen-devel@lists.xen.org
> >> Subject: RE: [Xen-devel] Failed to access register with invalid
> >> access size alignment
> >>
> >>>>> On 09.04.14 at 17:32, <Kelly.Zytaruk@amd.com> 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

Re: Failed to access register with invalid access size alignment

[Zytaruk, Kelly]

Hi Jan,

Just saw this message from you, must have missed it earlier.  I paused the guest on the access and found the EIP address pointing to an OS port access function in the Windows guest.  I wasn't able to gather any stack trace information so I couldn't tell how it was originally called.  I don't see any failures on bare metal so I presume that this is either a non-required access or it just happens to return a result that the caller is happy with.

Thanks,
Kelly

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Thursday, April 03, 2014 4:41 AM
> To: Zytaruk, Kelly
> Cc: Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Failed to access register with invalid access size
> alignment
> 
> >>> On 02.04.14 at 21:28, <Kelly.Zytaruk@amd.com> wrote:
> > I have seen the subject-line error message in a few posts but I
> > haven't yet seen a resolution for it yet.  Has anyone resolved this problem?
> >
> > The full error line from the log file is; [00:05.0]
> > xen_pt_pci_config_access_check: Error: Failed to access register with
> > invalid access size alignment. (addr: 0x0e, len: 4)
> >
> > Address 0x0e in PCIe config space is 2 byte aligned and can't be
> > accessed as a 4 byte read.
> 
> And hence one would think that it should be addressed in the guest OS rather
> than Xen or qemu. But of course it depends to some degree on whether real
> hardware permits the mis-aligned accesses - we may need to relax the
> restrictions if so.
> 
> Did you manage to find out where the bad request originates, and how it
> behaves when run on bare hardware?
> 
> Jan
> 

Re: Failed to access register with invalid access size alignment

[Konrad Rzeszutek Wilk]

On Wed, Apr 02, 2014 at 07:28:44PM +0000, Zytaruk, Kelly wrote:
> I have seen the subject-line error message in a few posts but I haven't yet seen a resolution for it yet.  Has anyone resolved this problem?
> 
> The full error line from the log file is;
> [00:05.0] xen_pt_pci_config_access_check: Error: Failed to access register with invalid access size alignment. (addr: 0x0e, len: 4)
> 

You could instrument QEMU to pause the guest immediately when this happens. Then
you can use xen_hvmtrace to figure the EIP and get an idea of where things are.

> Address 0x0e in PCIe config space is 2 byte aligned and can't be accessed as a 4 byte read.
> 
> I am passing an AMD graphics adapter into a guest as a secondary adapter.  I can connect with VNC and the PCI passthrough is successful as I can see the [00:05.0] device in Win7 device Manager but the device is "banged out" with the error "Windows has stopped this device because it has reported problems. (Code 43)".
> 
> The error occurs with both QEMU-upstream and QEMU-traditional.
> My configuration is Xen 4.5-unstable on Linux 3.13.4.
> 
> Thanks,
> Kelly
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Failed to access register with invalid access size alignment

[Zytaruk, Kelly]

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, April 04, 2014 10:00 AM
> To: Zytaruk, Kelly
> Cc: Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Failed to access register with invalid access size
> alignment
> 
> On Wed, Apr 02, 2014 at 07:28:44PM +0000, Zytaruk, Kelly wrote:
> > I have seen the subject-line error message in a few posts but I haven't yet seen
> a resolution for it yet.  Has anyone resolved this problem?
> >
> > The full error line from the log file is; [00:05.0]
> > xen_pt_pci_config_access_check: Error: Failed to access register with
> > invalid access size alignment. (addr: 0x0e, len: 4)
> >
> 
> You could instrument QEMU to pause the guest immediately when this happens.

Do you mean simply keeping QEMU in a while loop and not processing any more events when this happens like doing

    /* check offset alignment */
    if (address & (len-1))
    {
        PT_LOG_DEV(d, "Error: Failed to read register with invalid access size "
            "alignment. [Offset:%02xh][Length:%d]\n", address, len);
	stay_in_loop = true;
-->     while (stay_in_loop)  usleep (1000);   <--
        goto exit;
    }

or is there a more "elegant" way to pause the guest.

> Then you can use xen_hvmtrace to figure the EIP and get an idea of where
> things are.
> 

I googled "hvmtrace" and found a few code submissions but didn't find any information on how to use it.  Is there any documentation?


> > Address 0x0e in PCIe config space is 2 byte aligned and can't be accessed as a
> 4 byte read.
> >
> > I am passing an AMD graphics adapter into a guest as a secondary adapter.  I
> can connect with VNC and the PCI passthrough is successful as I can see the
> [00:05.0] device in Win7 device Manager but the device is "banged out" with the
> error "Windows has stopped this device because it has reported problems. (Code
> 43)".
> >
> > The error occurs with both QEMU-upstream and QEMU-traditional.
> > My configuration is Xen 4.5-unstable on Linux 3.13.4.
> >
> > Thanks,
> > Kelly
> >
> >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

Re: Failed to access register with invalid access size alignment

[Konrad Rzeszutek Wilk]

On Fri, Apr 04, 2014 at 02:33:55PM +0000, Zytaruk, Kelly wrote:
> 
> 
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Friday, April 04, 2014 10:00 AM
> > To: Zytaruk, Kelly
> > Cc: Xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] Failed to access register with invalid access size
> > alignment
> > 
> > On Wed, Apr 02, 2014 at 07:28:44PM +0000, Zytaruk, Kelly wrote:
> > > I have seen the subject-line error message in a few posts but I haven't yet seen
> > a resolution for it yet.  Has anyone resolved this problem?
> > >
> > > The full error line from the log file is; [00:05.0]
> > > xen_pt_pci_config_access_check: Error: Failed to access register with
> > > invalid access size alignment. (addr: 0x0e, len: 4)
> > >
> > 
> > You could instrument QEMU to pause the guest immediately when this happens.
> 
> Do you mean simply keeping QEMU in a while loop and not processing any more events when this happens like doing
> 
>     /* check offset alignment */
>     if (address & (len-1))
>     {
>         PT_LOG_DEV(d, "Error: Failed to read register with invalid access size "
>             "alignment. [Offset:%02xh][Length:%d]\n", address, len);
> 	stay_in_loop = true;
> -->     while (stay_in_loop)  usleep (1000);   <--
>         goto exit;
>     }
> 
> or is there a more "elegant" way to pause the guest.

Invoke the  xc_domain_pause function.

> 
> > Then you can use xen_hvmtrace to figure the EIP and get an idea of where
> > things are.
> > 
> 
> I googled "hvmtrace" and found a few code submissions but didn't find any information on how to use it.  Is there any documentation?

Try /usr/lib64/bin/xen/xenctx [it might be in a different location depending
on how you built Xen]
> 
> 
> > > Address 0x0e in PCIe config space is 2 byte aligned and can't be accessed as a
> > 4 byte read.
> > >
> > > I am passing an AMD graphics adapter into a guest as a secondary adapter.  I
> > can connect with VNC and the PCI passthrough is successful as I can see the
> > [00:05.0] device in Win7 device Manager but the device is "banged out" with the
> > error "Windows has stopped this device because it has reported problems. (Code
> > 43)".
> > >
> > > The error occurs with both QEMU-upstream and QEMU-traditional.
> > > My configuration is Xen 4.5-unstable on Linux 3.13.4.
> > >
> > > Thanks,
> > > Kelly
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> 

Re: Failed to access register with invalid access size alignment

[Nick]

Zytaruk, Kelly <Kelly.Zytaruk <at> amd.com> writes:

> 
> I have seen the subject-line error message in a few posts but I haven't 
yet seen a resolution for it yet.  Has
> anyone resolved this problem?
> 
> The full error line from the log file is;
> [00:05.0] xen_pt_pci_config_access_check: Error: Failed to access register 
with invalid access size
> alignment. (addr: 0x0e, len: 4)
> 
> Address 0x0e in PCIe config space is 2 byte aligned and can't be accessed 
as a 4 byte read.
> 
> I am passing an AMD graphics adapter into a guest as a secondary adapter.  
I can connect with VNC and the PCI
> passthrough is successful as I can see the [00:05.0] device in Win7 device 
Manager but the device is
> "banged out" with the error "Windows has stopped this device because it 
has reported problems. (Code 43)".
> 
> The error occurs with both QEMU-upstream and QEMU-traditional.
> My configuration is Xen 4.5-unstable on Linux 3.13.4.
> 
> Thanks,
> Kelly
> 

I am running into the same issue, on xen 4.4.0 and linux 3.14.1 exactly the 
same error including the device number 5. This is with a Win8 Dom0 and a 
7970 GPU.