Re: [PATCH] vpci/msix: handle accesses adjacent to the MSI-X table

[Jan Beulich <jbeulich@xxxxxxxx>]

On 14.03.2023 17:34, Roger Pau Monné wrote:
> On Tue, Mar 14, 2023 at 04:46:19PM +0100, Jan Beulich wrote:
>> On 14.03.2023 14:54, Roger Pau Monné wrote:
>>> On Tue, Mar 14, 2023 at 12:56:33PM +0100, Jan Beulich wrote:
>>>> On 14.03.2023 11:13, Roger Pau Monne wrote:
>>>> I'm also concerned of misaligned accesses: While we can't keep the
>>>> guest from doing such on pages we don't intercept, depending on the kind
>>>> of anomalies such may cause the effects there may be contained to that
>>>> guest. When doing the accesses from the hypervisor, bad effects could
>>>> affect the entire system. (FTAOD I don't mean to constrain guests, but I
>>>> do think we need to consider splitting misaligned accesses.)
>>>
>>> I was also wondering about misaligned accesses.  Should be allow dom0
>>> any kind of access, while limiting domUs to aligned only?
>>
>> I guess the code would be simpler we we treated both equally. As said,
>> my goal is not to refuse misaligned accesses, but to break them up. To
>> keep things simple we might even use purely byte accesses (and then
>> perhaps simply REP MOVSB). Special casing Dom0 would only add code for
>> no real gain.
> 
> Hm, I would be worried about then breaking the requirement of some
> registers being accessed using a specific size, but again we are
> dealing with misaligned accesses to a region that shouldn't contain
> registers in the first place.

Well, you name it: We're talking about a specific-width access which
at the same is misaligned. That doesn't sound very likely, and imo
wants caring about the earliest when such a case actually arises.

> FWIW, the device I currently have that has registers in the same page
> as the MSIX and the PBA tables is fine with limiting such accesses to
> aligned only.
> 
> What is it that worries you about Xen relying unaligned accesses
> instead of just the domain itself doing it on any other BAR MMIO it
> has directly mapped into the p2m?  Any error generated by the device
> in such setup would likely have the same effect, regardless of whether
> the access is in Xen or domain context.

It's more that doing this in Xen doesn't feel well. If I should provide
a contrived scenario, I'd point at #MC potentially being raised for
such an access. If further we'd assume we had better machine check
handling, then dealing with #MC coming from a guest can be expected to
be more likely to keep the host alive than if the #MC was raised in Xen
(and e.g. - didn't check here - possibly with some lock held).

Jan