On 12.03.20 16:11, Jan Beulich wrote:
On 12.03.2020 14:44, Roger Pau Monné wrote:
On Thu, Mar 12, 2020 at 12:12:12PM +0100, Jürgen Groß wrote:
On 12.03.20 11:56, Roger Pau Monné wrote:
On Thu, Mar 12, 2020 at 09:59:48AM +0100, Jan Beulich wrote:
On 11.03.2020 19:04, Andrew Cooper wrote:
Spec
On 12.03.2020 14:44, Roger Pau Monné wrote:
> On Thu, Mar 12, 2020 at 12:12:12PM +0100, Jürgen Groß wrote:
>> On 12.03.20 11:56, Roger Pau Monné wrote:
>>> On Thu, Mar 12, 2020 at 09:59:48AM +0100, Jan Beulich wrote:
On 11.03.2020 19:04, Andrew Cooper wrote:
> Specifically, this is a switc
On Thu, Mar 12, 2020 at 12:12:12PM +0100, Jürgen Groß wrote:
> On 12.03.20 11:56, Roger Pau Monné wrote:
> > On Thu, Mar 12, 2020 at 09:59:48AM +0100, Jan Beulich wrote:
> > > On 11.03.2020 19:04, Andrew Cooper wrote:
> > > > Specifically, this is a switch from an HVM vcpu, to a PV vcpu, where the
On 12.03.20 11:56, Roger Pau Monné wrote:
On Thu, Mar 12, 2020 at 09:59:48AM +0100, Jan Beulich wrote:
On 11.03.2020 19:04, Andrew Cooper wrote:
Specifically, this is a switch from an HVM vcpu, to a PV vcpu, where the
mapcache code tries to access the per-domain mappings on the HVM monitor
tabl
On 12.03.2020 11:56, Roger Pau Monné wrote:
> On Thu, Mar 12, 2020 at 09:59:48AM +0100, Jan Beulich wrote:
>> On 11.03.2020 19:04, Andrew Cooper wrote:
>>> Specifically, this is a switch from an HVM vcpu, to a PV vcpu, where the
>>> mapcache code tries to access the per-domain mappings on the HVM m
On Thu, Mar 12, 2020 at 09:59:48AM +0100, Jan Beulich wrote:
> On 11.03.2020 19:04, Andrew Cooper wrote:
> > Specifically, this is a switch from an HVM vcpu, to a PV vcpu, where the
> > mapcache code tries to access the per-domain mappings on the HVM monitor
> > table. It ends up trying to recursi
On 11.03.2020 19:04, Andrew Cooper wrote:
> Specifically, this is a switch from an HVM vcpu, to a PV vcpu, where the
> mapcache code tries to access the per-domain mappings on the HVM monitor
> table. It ends up trying to recursively acquire the mapcache lock while
> trying to walk %cr2 to identif
Hello,
Testing has encountered this deadlock:
(XEN) Watchdog timer detects that CPU0 is stuck!
(XEN) [ Xen-4.14.0-9.0.4-d x86_64 debug=y Not tainted ]
(XEN) CPU: 0
(XEN) RIP: e008:[] _spin_lock+0x34/0x5e
(XEN) RFLAGS: 0002 CONTEXT: hypervisor (d0v0)
(XEN) rax: