From XSA-201, we know that, a guest could trigger SErrors when accessing
memory mapped HW in a non-conventional way. In the patches for XSA-201,
we crash the guest when we captured such asynchronous aborts to avoid data
corruption.
In order to distinguish guest-generated SErrors from hypervisor-ge
Thank you Wei. I committed this series. I fixed on commit patch #16 that
has 2 asserts.
On Wed, 5 Apr 2017, Wei Chen wrote:
> From XSA-201, we know that, a guest could trigger SErrors when accessing
> memory mapped HW in a non-conventional way. In the patches for XSA-201,
> we crash the guest when
Thanks to you and Julien :)
On 2017/4/6 3:18, Stefano Stabellini wrote:
> Thank you Wei. I committed this series. I fixed on commit patch #16 that
> has 2 asserts.
>
> On Wed, 5 Apr 2017, Wei Chen wrote:
>> From XSA-201, we know that, a guest could trigger SErrors when accessing
>> memory mapped
Hi,
I just noticed that commit b32d442abd "setup vwfi correctly on cpu0" has
not been revered as asked by Stefano (see [1]).
Stefano, can you revert it?
Cheers,
[1]
https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg00264.html
On 05/04/17 20:18, Stefano Stabellini wrote:
Tha
Done. I have also made the backports to the stable trees.
On Fri, 7 Apr 2017, Julien Grall wrote:
> Hi,
>
> I just noticed that commit b32d442abd "setup vwfi correctly on cpu0" has not
> been revered as asked by Stefano (see [1]).
>
> Stefano, can you revert it?
>
> Cheers,
>
> [1] https://lis
