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

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

> >
> > >>> 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 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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel


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