[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation
> -----Original Message----- > From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > Sent: 28 November 2017 11:26 > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx> > Cc: Julien Grall <julien.grall@xxxxxxx>; Andrew Cooper > <Andrew.Cooper3@xxxxxxxxxx>; xen-devel <xen- > devel@xxxxxxxxxxxxxxxxxxxx> > Subject: RE: [PATCH] x86/HVM: fix interaction between internal and extern > emulation > > >>> On 28.11.17 at 12:06, <Paul.Durrant@xxxxxxxxxx> wrote: > > Yes, it appears that mmio_retry is only set when the underlying emulation > > returned X86EMUL_OKAY but not all reps were completed. If the > underlying > > emulation did not return X86EMUL_RETRY then I can't figure out why > > vio->io_completion should need to be set to anything other than > > HVMIO_no_completion since any other return value indicates there should > be > > nothing pending. > > So am I getting it right that you're suggesting to remove the > mmio_retry part of the condition in hvm_emulate_one_insn()? > That looks like it might work (I was previously only considering > to get rid of mmio_retry altogether, and that didn't look like a > viable route). Yes, that's what I'm suggesting. I really can't see why it is needed. It could have been a mistake in my original patches or a semantic change in a subsequent patch, but it certainly looks wrong in current context. Andrew has just sent me his xtf repro so I'll give the change a go with that. Paul Paul > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |