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

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

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, April 03, 2014 4:41 AM
> To: Zytaruk, Kelly
> Cc: Xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Failed to access register with invalid access size
> alignment
> 
> >>> On 02.04.14 at 21:28, <Kelly.Zytaruk@xxxxxxx> 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
> 



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