|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
On 10/08/18 13:43, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] >> Sent: 10 August 2018 13:37 >> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx> >> Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx> >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >>>>> On 10.08.18 at 14:22, <Paul.Durrant@xxxxxxxxxx> wrote: >>>> -----Original Message----- >>>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] >>>> Sent: 10 August 2018 13:13 >>>> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx> >>>> Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx> >>>> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >>>> >>>>>>> On 10.08.18 at 14:08, <Paul.Durrant@xxxxxxxxxx> wrote: >>>>>> -----Original Message----- >>>>>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] >>>>>> Sent: 10 August 2018 13:02 >>>>>> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx> >>>>>> Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx> >>>>>> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >>>>>> >>>>>>>>> On 10.08.18 at 12:37, <paul.durrant@xxxxxxxxxx> wrote: >>>>>>> These are probably both candidates for back-port. >>>>>>> >>>>>>> Paul Durrant (2): >>>>>>> x86/hvm/ioreq: MMIO range checking completely ignores direction >> flag >>>>>>> x86/hvm/emulate: make sure rep I/O emulation does not cross GFN >>>>>>> boundaries >>>>>>> >>>>>>> xen/arch/x86/hvm/emulate.c | 17 ++++++++++++++++- >>>>>>> xen/arch/x86/hvm/ioreq.c | 15 ++++++++++----- >>>>>>> 2 files changed, 26 insertions(+), 6 deletions(-) >>>>>> I take it this isn't yet what we've talked about yesterday on irc? >>>>>> >>>>> This is the band-aid fix. I can now show correct handling of a rep mov >>>>> walking off MMIO into RAM. >>>> But that's not the problem we're having. In our case the bad behavior >>>> is with a single MOV. That's why I had assumed that your plan to fiddle >>>> with null_handler would help in our case as well, while this series clearly >>>> won't (afaict). >>>> >>> Oh, I see. A single MOV spanning MMIO and RAM has undefined behaviour >> though >>> as I understand it. Am I incorrect? >> I'm not aware of SDM or PM saying anything like this. Anyway, the >> specific case where this is being observed as an issue is when >> accessing the last few bytes of a normal RAM page followed by a >> ballooned out one. The balloon driver doesn't remove the virtual >> mapping of such pages (presumably in order to not shatter super >> pages); observation is with the old XenoLinux one, but from code >> inspection the upstream one behaves the same. >> >> Unless we want to change the balloon driver's behavior, at least >> this specific case needs to be considered having defined behavior, >> I think. >> > Ok. I'll see what I can do. It is a software error to try and cross boundaries. Modern processors do their best to try and cause the correct behaviour to occur, albeit with a massive disclaimer about the performance hit. Older processors didn't cope. As far as I'm concerned, its fine to terminate a emulation which crosses a boundary with the null ops. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |