>>> On 04.09.18 at 18:24, wrote:
> On 04/09/18 17:11, Juergen Gross wrote:
>> On 16/08/18 13:27, Jan Beulich wrote:
>> On 16.08.18 at 12:56, wrote:
On 16/08/18 11:29, Jan Beulich wrote:
> Following some further discussion with Andrew, he looks to be
> convinced that the issue is
On 04/09/18 17:11, Juergen Gross wrote:
> On 16/08/18 13:27, Jan Beulich wrote:
> On 16.08.18 at 12:56, wrote:
>>> On 16/08/18 11:29, Jan Beulich wrote:
Following some further discussion with Andrew, he looks to be
convinced that the issue is to be fixed in the balloon driver,
w
On 16/08/18 13:27, Jan Beulich wrote:
On 16.08.18 at 12:56, wrote:
>> On 16/08/18 11:29, Jan Beulich wrote:
>>> Following some further discussion with Andrew, he looks to be
>>> convinced that the issue is to be fixed in the balloon driver,
>>> which so far (intentionally afaict) does not rem
On Thu, Aug 30, Jan Beulich wrote:
> approach): One is Paul's idea of making null_handler actually retrieve
> RAM contents when (part of) the access touches RAM. Another might
This works for me:
static int null_read(const struct hvm_io_handler *io_handler,
uint64_t addr,
>>> On 30.08.18 at 10:10, wrote:
> On Wed, Aug 29, Olaf Hering wrote:
>
>> On Mon, Aug 13, Jan Beulich wrote:
>>
>> > And hence the consideration of mapping in an all zeros page
>> > instead. This is because of the way __hvmemul_read() /
>> > __hvm_copy() work: The latter doesn't tell its caller
On Wed, Aug 29, Olaf Hering wrote:
> On Mon, Aug 13, Jan Beulich wrote:
>
> > And hence the consideration of mapping in an all zeros page
> > instead. This is because of the way __hvmemul_read() /
> > __hvm_copy() work: The latter doesn't tell its caller how many
> > bytes it was able to read, an
>>> On 29.08.18 at 13:09, wrote:
> On 29/08/18 12:00, Olaf Hering wrote:
>> On Wed, Aug 29, Andrew Cooper wrote:
>>
>>> Architecturally speaking, handing #MC back is probably the closest we
>>> can get to sensible behaviour, but it is still a bug that Linux is
>>> touching the ballooned out page i
On 29/08/18 13:09, Andrew Cooper wrote:
> On 29/08/18 12:00, Olaf Hering wrote:
>> On Wed, Aug 29, Andrew Cooper wrote:
>>
>>> Architecturally speaking, handing #MC back is probably the closest we
>>> can get to sensible behaviour, but it is still a bug that Linux is
>>> touching the ballooned out
On 29/08/18 12:09, Andrew Cooper wrote:
> On 29/08/18 12:00, Olaf Hering wrote:
>> On Wed, Aug 29, Andrew Cooper wrote:
>>
>>> Architecturally speaking, handing #MC back is probably the closest we
>>> can get to sensible behaviour, but it is still a bug that Linux is
>>> touching the ballooned out
On 29/08/18 12:00, Olaf Hering wrote:
> On Wed, Aug 29, Andrew Cooper wrote:
>
>> Architecturally speaking, handing #MC back is probably the closest we
>> can get to sensible behaviour, but it is still a bug that Linux is
>> touching the ballooned out page in the first place.
> Well, the issue is t
On Wed, Aug 29, Andrew Cooper wrote:
> Architecturally speaking, handing #MC back is probably the closest we
> can get to sensible behaviour, but it is still a bug that Linux is
> touching the ballooned out page in the first place.
Well, the issue is that a read crosses a page boundary. If that w
On 29/08/18 11:36, Olaf Hering wrote:
> On Mon, Aug 13, Jan Beulich wrote:
>
>> And hence the consideration of mapping in an all zeros page
>> instead. This is because of the way __hvmemul_read() /
>> __hvm_copy() work: The latter doesn't tell its caller how many
>> bytes it was able to read, and h
On Mon, Aug 13, Jan Beulich wrote:
> And hence the consideration of mapping in an all zeros page
> instead. This is because of the way __hvmemul_read() /
> __hvm_copy() work: The latter doesn't tell its caller how many
> bytes it was able to read, and hence the former considers the
> entire range
On 16/08/18 13:27, Jan Beulich wrote:
On 16.08.18 at 12:56, wrote:
>> On 16/08/18 11:29, Jan Beulich wrote:
>>> Following some further discussion with Andrew, he looks to be
>>> convinced that the issue is to be fixed in the balloon driver,
>>> which so far (intentionally afaict) does not rem
>>> On 16.08.18 at 12:56, wrote:
> On 16/08/18 11:29, Jan Beulich wrote:
>> Following some further discussion with Andrew, he looks to be
>> convinced that the issue is to be fixed in the balloon driver,
>> which so far (intentionally afaict) does not remove the direct
>> map entries for ballooned
On 13/08/18 07:50, Jan Beulich wrote:
On 10.08.18 at 18:37, wrote:
>> On 10/08/18 17:30, George Dunlap wrote:
>>> Sorry, what exactly is the issue here? Linux has a function called
>>> load_unaligned_zeropad() which is reading into a ballooned region?
> Yes.
>
>>> Fundamentally, a ballooned
On 16/08/18 11:29, Jan Beulich wrote:
On 13.08.18 at 08:50, wrote:
> On 10.08.18 at 18:37, wrote:
>>> On 10/08/18 17:30, George Dunlap wrote:
Sorry, what exactly is the issue here? Linux has a function called
load_unaligned_zeropad() which is reading into a ballooned region?
>
>>> On 13.08.18 at 08:50, wrote:
On 10.08.18 at 18:37, wrote:
> > On 10/08/18 17:30, George Dunlap wrote:
> >> Sorry, what exactly is the issue here? Linux has a function called
> >> load_unaligned_zeropad() which is reading into a ballooned region?
>
> Yes.
>
> >> Fundamentally, a balloo
>>> On 10.08.18 at 18:37, wrote:
> On 10/08/18 17:30, George Dunlap wrote:
>> Sorry, what exactly is the issue here? Linux has a function called
>> load_unaligned_zeropad() which is reading into a ballooned region?
Yes.
>> Fundamentally, a ballooned page is one which has been allocated to a
>>
;>>> To: Paul Durrant
>>>> Cc: Andrew Cooper ; xen-devel >>> de...@lists.xenproject.org>
>>>> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>>>
>>>>>>> On 10.08.18 at 17:08, wrote:
>>>>>> ---
evel >> de...@lists.xenproject.org>
>>> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>>
>>>>>> On 10.08.18 at 17:08, wrote:
>>>>> -Original Message-
>>>>> From: Andrew Cooper
>>>>> Sent
>>> On 10.08.18 at 17:35, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 10 August 2018 16:31
>> To: Paul Durrant
>> Cc: Andrew Cooper ; xen-devel > de...@lists.xenproject.org>
>> Subjec
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2018 16:31
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>
> >&
>>> On 10.08.18 at 17:08, wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 10 August 2018 13:56
>> To: Paul Durrant ; 'Jan Beulich'
>>
>> Cc: xen-devel
>> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO
> -Original Message-
> From: Andrew Cooper
> Sent: 10 August 2018 13:56
> To: Paul Durrant ; 'Jan Beulich'
>
> Cc: xen-devel
> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>
> On 10/08/18 13:43, Paul Durrant wrote:
> >> ---
On 10/08/18 13:43, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 10 August 2018 13:37
>> To: Paul Durrant
>> Cc: xen-devel
>> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
&
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2018 13:37
> To: Paul Durrant
> Cc: xen-devel
> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>
> >>> On 10.08.18 at 14:22, wrote:
> >> -Or
>>> On 10.08.18 at 14:22, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 10 August 2018 13:13
>> To: Paul Durrant
>> Cc: xen-devel
>> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2018 13:13
> To: Paul Durrant
> Cc: xen-devel
> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>
> >>> On 10.08.18 at 14:08, wrote:
> >> -Or
>>> On 10.08.18 at 14:08, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 10 August 2018 13:02
>> To: Paul Durrant
>> Cc: xen-devel
>> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2018 13:02
> To: Paul Durrant
> Cc: xen-devel
> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>
> >>> On 10.08.18 at 12:37, wrote:
> > These are
>>> On 10.08.18 at 12:37, 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
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
33 matches
Mail list logo
