On 22/06/2017 09:23, Marek Marczykowski-Górecki wrote:
> [resurrecting old thread...]
>
> On Mon, Jan 16, 2017 at 11:41:55PM +, Andrew Cooper wrote:
>> On 16/01/2017 23:06, Marek Marczykowski-Górecki wrote:
>>> On Mon, Jan 16, 2017 at 05:17:59AM -0700, Jan Beulich wrote:
2) When the guest
[resurrecting old thread...]
On Mon, Jan 16, 2017 at 11:41:55PM +, Andrew Cooper wrote:
> On 16/01/2017 23:06, Marek Marczykowski-Górecki wrote:
> > On Mon, Jan 16, 2017 at 05:17:59AM -0700, Jan Beulich wrote:
> >> 2) When the guest issues stac()/clac(), it indicates to Xen _its own_
> >> inte
On 16/01/2017 23:06, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 16, 2017 at 05:17:59AM -0700, Jan Beulich wrote:
> On 14.01.17 at 03:52, wrote:
>>> On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote:
In a native situation, SMAP raises #PF if hardware tries to follow a
On Mon, Jan 16, 2017 at 05:17:59AM -0700, Jan Beulich wrote:
> >>> On 14.01.17 at 03:52, wrote:
> > On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote:
> >> In a native situation, SMAP raises #PF if hardware tries to follow a
> >> user pointer outside of an area whitelisted by the kerne
>>> On 14.01.17 at 03:52, wrote:
> On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote:
>> In a native situation, SMAP raises #PF if hardware tries to follow a
>> user pointer outside of an area whitelisted by the kernel. (The
>> copy_*_guest path suppresses #PF, opting instead to retur
On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote:
> On 13/01/2017 20:32, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 07:54:01PM +, Andrew Cooper wrote:
> >> This is a guest kernel bug. The guest kernel has used SMAP to say
> >> "please disallow all userspace acce
On 13/01/2017 20:32, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 07:54:01PM +, Andrew Cooper wrote:
>> On 13/01/17 19:40, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote:
On 13/01/17 18:59, Marek Marczykowski-Górecki wrote
On Fri, Jan 13, 2017 at 07:54:01PM +, Andrew Cooper wrote:
> On 13/01/17 19:40, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote:
> >> On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
> >>> On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew C
On 13/01/17 19:40, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote:
>> On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote:
> On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
> >> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
> >>> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew C
On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
>> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
Can you get the result of this piece of debugging in
On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
> >> Can you get the result of this piece of debugging in the failure case?
> > I've got this:
> > ** d4v0 CFG(24,
On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
>> On 13/01/17 18:03, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote:
On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
> On 13/01/17 18:03, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote:
> >> On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
> >>> Hi,
> >>>
> >>> I have a strange problem - xc_evtc
On 13/01/17 18:03, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote:
>> On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
>>> Hi,
>>>
>>> I have a strange problem - xc_evtchn_status fails when running in HVM,
>>> while exactly the same code (same
On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote:
> On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > I have a strange problem - xc_evtchn_status fails when running in HVM,
> > while exactly the same code (same kernel, same application etc) works
> > fine in PV. I've
On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I have a strange problem - xc_evtchn_status fails when running in HVM,
> while exactly the same code (same kernel, same application etc) works
> fine in PV. I've narrowed it down to copy_from_guest call in
> common/event_channel.c, but
Hi,
I have a strange problem - xc_evtchn_status fails when running in HVM,
while exactly the same code (same kernel, same application etc) works
fine in PV. I've narrowed it down to copy_from_guest call in
common/event_channel.c, but no idea why it fails there. Xen version is
4.8.0. kernel is kern
18 matches
Mail list logo