On 5/14/19 5:16 PM, Jan Beulich wrote:
On 14.05.19 at 15:47, wrote:
Mem event emulation failed (5): d5v0 32bit @ 001b:6d96efff -> c5 f9 f5
05 c0 be ad 6d c5 e1 fe 1d a0 20 af 6d
Looking at the source code, the emulator does appear to support
vpmaddwd, however only for EVEX:
http://xenbits.x
>>> On 14.05.19 at 15:47, wrote:
> Mem event emulation failed (5): d5v0 32bit @ 001b:6d96efff -> c5 f9 f5
> 05 c0 be ad 6d c5 e1 fe 1d a0 20 af 6d
>
> Looking at the source code, the emulator does appear to support
> vpmaddwd, however only for EVEX:
>
> http://xenbits.xen.org/gitweb/?p=xen.git
On 5/13/19 5:15 PM, Razvan Cojocaru wrote:
On 5/13/19 5:06 PM, Jan Beulich wrote:
On 13.05.19 at 15:58, wrote:
On 11/27/18 12:49 PM, Razvan Cojocaru wrote:
With a sufficiently complete insn emulator, single-stepping should
not be needed at all imo. Granted we're not quite there yet with
the e
On 5/13/19 5:06 PM, Jan Beulich wrote:
On 13.05.19 at 15:58, wrote:
On 11/27/18 12:49 PM, Razvan Cojocaru wrote:
With a sufficiently complete insn emulator, single-stepping should
not be needed at all imo. Granted we're not quite there yet with
the emulator, but we've made quite a bit of progr
>>> On 13.05.19 at 15:58, wrote:
> On 11/27/18 12:49 PM, Razvan Cojocaru wrote:
>>> With a sufficiently complete insn emulator, single-stepping should
>>> not be needed at all imo. Granted we're not quite there yet with
>>> the emulator, but we've made quite a bit of progress. As before,
>>> if th
On 11/27/18 12:49 PM, Razvan Cojocaru wrote:
With a sufficiently complete insn emulator, single-stepping should
not be needed at all imo. Granted we're not quite there yet with
the emulator, but we've made quite a bit of progress. As before,
if there are particular instructions you know of that t
On 19.12.2018 19:40, Roger Pau Monné wrote:
> On Wed, Dec 19, 2018 at 04:49:43PM +, Alexandru Stefan ISAILA wrote:
>> On 27.11.2018 13:32, Roger Pau Monné wrote:
>>> Would it be possible to add some kind of flag to the emulator to
>>> signal whether p2m restrictions should be enforced/ignored
>>> On 19.12.18 at 17:49, wrote:
> On 27.11.2018 13:32, Roger Pau Monné wrote:
>> Would it be possible to add some kind of flag to the emulator to
>> signal whether p2m restrictions should be enforced/ignored?
>> hvmemul_acquire_page seems like a suitable place, but I'm not that
>> familiar with t
On Wed, Dec 19, 2018 at 04:49:43PM +, Alexandru Stefan ISAILA wrote:
> On 27.11.2018 13:32, Roger Pau Monné wrote:
> > Would it be possible to add some kind of flag to the emulator to
> > signal whether p2m restrictions should be enforced/ignored?
> > hvmemul_acquire_page seems like a suitable
On 27.11.2018 13:32, Roger Pau Monné wrote:
> Would it be possible to add some kind of flag to the emulator to
> signal whether p2m restrictions should be enforced/ignored?
> hvmemul_acquire_page seems like a suitable place, but I'm not that
> familiar with the emulator.
>
> Then you could generat
On 11/27/18 1:59 PM, Andrew Cooper wrote:
> On 27/11/2018 11:45, Razvan Cojocaru wrote:
>> On 11/27/18 1:32 PM, Roger Pau Monné wrote:
>>> Would it be possible to add some kind of flag to the emulator to
>>> signal whether p2m restrictions should be enforced/ignored?
>>> hvmemul_acquire_page seems
On 27/11/2018 11:45, Razvan Cojocaru wrote:
> On 11/27/18 1:32 PM, Roger Pau Monné wrote:
>> Would it be possible to add some kind of flag to the emulator to
>> signal whether p2m restrictions should be enforced/ignored?
>> hvmemul_acquire_page seems like a suitable place, but I'm not that
>> famil
On 11/27/18 1:32 PM, Roger Pau Monné wrote:
> Would it be possible to add some kind of flag to the emulator to
> signal whether p2m restrictions should be enforced/ignored?
> hvmemul_acquire_page seems like a suitable place, but I'm not that
> familiar with the emulator.
>
> Then you could generat
>> About the emulator and events: if we could have a toggle for the
>> emulator to tell it "emulate the current instruction and send out a
>> vm_event only if it touches a protected page that's NOT part of the page
>> walk", that would also work - though I can't at this point tell how
>> feasible t
On Tue, Nov 27, 2018 at 12:31:35PM +0200, Razvan Cojocaru wrote:
> >> _However_, please picture an instruction that both writes into a page P1
> >> we're interested in, _and_ causes a write into a read-only page-walk
> >> related page P2. Emulating the current instruction, as the upstream
> >> patc
>>> On 27.11.18 at 11:49, wrote:
> On 11/23/18 11:07 AM, Jan Beulich wrote:
> On 22.11.18 at 19:24, wrote:
>>> _However_, please picture an instruction that both writes into a page P1
>>> we're interested in, _and_ causes a write into a read-only page-walk
>>> related page P2. Emulating the c
On 11/23/18 11:07 AM, Jan Beulich wrote:
On 22.11.18 at 19:24, wrote:
>> _However_, please picture an instruction that both writes into a page P1
>> we're interested in, _and_ causes a write into a read-only page-walk
>> related page P2. Emulating the current instruction, as the upstream
>> p
>> _However_, please picture an instruction that both writes into a page P1
>> we're interested in, _and_ causes a write into a read-only page-walk
>> related page P2. Emulating the current instruction, as the upstream
>> patch does, does eliminate the vm_event caused by writing into P2, but
>> wit
>>> On 23.11.18 at 09:54, wrote:
> On Thu, Nov 22, 2018 at 08:24:52PM +0200, Razvan Cojocaru wrote:
>> What this patch attempts to do is to mark P1 rwx (so allow the write),
>> then put the faulting VCPU into singlestep mode, then restore the
>> restrictions after it has finished single stepping.
>>> On 22.11.18 at 19:24, wrote:
> _However_, please picture an instruction that both writes into a page P1
> we're interested in, _and_ causes a write into a read-only page-walk
> related page P2. Emulating the current instruction, as the upstream
> patch does, does eliminate the vm_event caused
On Thu, Nov 22, 2018 at 08:24:52PM +0200, Razvan Cojocaru wrote:
> On 11/22/18 7:08 PM, Roger Pau Monné wrote:
> > On Thu, Nov 22, 2018 at 06:52:07PM +0200, Razvan Cojocaru wrote:
> >> On 11/22/18 5:37 PM, Roger Pau Monné wrote:
> >>> I don't think you are supposed to try to pause other vcpus while
On 11/22/18 7:08 PM, Roger Pau Monné wrote:
> On Thu, Nov 22, 2018 at 06:52:07PM +0200, Razvan Cojocaru wrote:
>> On 11/22/18 5:37 PM, Roger Pau Monné wrote:
>>> I don't think you are supposed to try to pause other vcpus while
>>> holding a lock, as you can see it's quite likely that you will end u
On Thu, Nov 22, 2018 at 06:52:07PM +0200, Razvan Cojocaru wrote:
> On 11/22/18 5:37 PM, Roger Pau Monné wrote:
> > I don't think you are supposed to try to pause other vcpus while
> > holding a lock, as you can see it's quite likely that you will end up
> > deadlocking because the vCPU you are tryi
On 11/22/18 5:37 PM, Roger Pau Monné wrote:
> I don't think you are supposed to try to pause other vcpus while
> holding a lock, as you can see it's quite likely that you will end up
> deadlocking because the vCPU you are trying to pause is stuck waiting
> on the lock that you are holding.
>
> You
On Thu, Nov 22, 2018 at 05:25:02PM +0200, Razvan Cojocaru wrote:
> On 11/22/18 4:49 PM, Roger Pau Monné wrote:
> > On Thu, Nov 22, 2018 at 02:48:07PM +0200, Razvan Cojocaru wrote:
> >> On 11/22/18 12:58 PM, Roger Pau Monné wrote:
> >>> On Thu, Nov 22, 2018 at 12:14:59PM +0200, Razvan Cojocaru wrote
On 11/22/18 4:49 PM, Roger Pau Monné wrote:
> On Thu, Nov 22, 2018 at 02:48:07PM +0200, Razvan Cojocaru wrote:
>> On 11/22/18 12:58 PM, Roger Pau Monné wrote:
>>> On Thu, Nov 22, 2018 at 12:14:59PM +0200, Razvan Cojocaru wrote:
On 11/22/18 12:05 PM, Roger Pau Monné wrote:
> On Wed, Nov 21,
On Thu, Nov 22, 2018 at 02:48:07PM +0200, Razvan Cojocaru wrote:
> On 11/22/18 12:58 PM, Roger Pau Monné wrote:
> > On Thu, Nov 22, 2018 at 12:14:59PM +0200, Razvan Cojocaru wrote:
> >> On 11/22/18 12:05 PM, Roger Pau Monné wrote:
> >>> On Wed, Nov 21, 2018 at 08:55:48PM +0200, Razvan Cojocaru wrot
On 11/22/18 12:58 PM, Roger Pau Monné wrote:
> On Thu, Nov 22, 2018 at 12:14:59PM +0200, Razvan Cojocaru wrote:
>> On 11/22/18 12:05 PM, Roger Pau Monné wrote:
>>> On Wed, Nov 21, 2018 at 08:55:48PM +0200, Razvan Cojocaru wrote:
On 11/16/18 7:04 PM, Roger Pau Monné wrote:
>> +i
On Thu, Nov 22, 2018 at 12:14:59PM +0200, Razvan Cojocaru wrote:
> On 11/22/18 12:05 PM, Roger Pau Monné wrote:
> > On Wed, Nov 21, 2018 at 08:55:48PM +0200, Razvan Cojocaru wrote:
> >> On 11/16/18 7:04 PM, Roger Pau Monné wrote:
> +if ( a == v )
> +continue;
>
On 11/22/18 12:05 PM, Roger Pau Monné wrote:
> On Wed, Nov 21, 2018 at 08:55:48PM +0200, Razvan Cojocaru wrote:
>> On 11/16/18 7:04 PM, Roger Pau Monné wrote:
+if ( a == v )
+continue;
+
+/* Pause, synced. */
+while ( !a->
On Thu, Nov 22, 2018 at 09:50:28AM +, Alexandru Stefan ISAILA wrote:
>
> On 21.11.2018 20:55, Razvan Cojocaru wrote:
> >> +if ( a == v )
> >> +continue;
> >> +
> >> +/* Pause, synced. */
> >> +while ( !a->arch.in_host )
> > Why not use a->is_
On Wed, Nov 21, 2018 at 08:55:48PM +0200, Razvan Cojocaru wrote:
> On 11/16/18 7:04 PM, Roger Pau Monné wrote:
> >> +if ( a == v )
> >> +continue;
> >> +
> >> +/* Pause, synced. */
> >> +while ( !a->arch.in_host )
> > Why not use a->is_running as
>>> On 22.11.18 at 10:50, wrote:
> On 21.11.2018 20:55, Razvan Cojocaru wrote:
>>> +if ( a == v )
>>> +continue;
>>> +
>>> +/* Pause, synced. */
>>> +while ( !a->arch.in_host )
>> Why not use a->is_running as a way to know whether the vCPU is
>>
On 21.11.2018 20:55, Razvan Cojocaru wrote:
>> +if ( a == v )
>> +continue;
>> +
>> +/* Pause, synced. */
>> +while ( !a->arch.in_host )
> Why not use a->is_running as a way to know whether the vCPU is
> running?
>
> I think the logic of using v
On 11/16/18 7:04 PM, Roger Pau Monné wrote:
>> +if ( a == v )
>> +continue;
>> +
>> +/* Pause, synced. */
>> +while ( !a->arch.in_host )
> Why not use a->is_running as a way to know whether the vCPU is
> running?
>
> I think the logic of using vc
On 21.11.2018 13:41, Roger Pau Monné wrote:
> On Wed, Nov 21, 2018 at 10:28:18AM +, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 21.11.2018 11:56, Roger Pau Monné wrote:
>>> On Mon, Nov 19, 2018 at 03:56:14PM +, Alexandru Stefan ISAILA wrote:
On 19.11.2018 17:08, Roger Pau Monné wrote:
On Wed, Nov 21, 2018 at 10:28:18AM +, Alexandru Stefan ISAILA wrote:
>
>
> On 21.11.2018 11:56, Roger Pau Monné wrote:
> > On Mon, Nov 19, 2018 at 03:56:14PM +, Alexandru Stefan ISAILA wrote:
> >> On 19.11.2018 17:08, Roger Pau Monné wrote:
> > Also, after looking at the code I'm not sure
On 21.11.2018 11:56, Roger Pau Monné wrote:
> On Mon, Nov 19, 2018 at 03:56:14PM +, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 19.11.2018 17:08, Roger Pau Monné wrote:
>>> On Mon, Nov 19, 2018 at 01:30:09PM +, Alexandru Stefan ISAILA wrote:
>> +/* Now transform our RWX values in a
On Mon, Nov 19, 2018 at 03:56:14PM +, Alexandru Stefan ISAILA wrote:
>
>
> On 19.11.2018 17:08, Roger Pau Monné wrote:
> > On Mon, Nov 19, 2018 at 01:30:09PM +, Alexandru Stefan ISAILA wrote:
> +/* Now transform our RWX values in a XENMEM_access_* constant. */
> +if ( r
On 19.11.2018 17:08, Roger Pau Monné wrote:
> On Mon, Nov 19, 2018 at 01:30:09PM +, Alexandru Stefan ISAILA wrote:
+/* Now transform our RWX values in a XENMEM_access_* constant. */
+if ( r == 0 && w == 0 && x == 0 )
+new_access = XENMEM_access_n;
+else
On Mon, Nov 19, 2018 at 01:30:09PM +, Alexandru Stefan ISAILA wrote:
> >> +/* Now transform our RWX values in a XENMEM_access_* constant. */
> >> +if ( r == 0 && w == 0 && x == 0 )
> >> +new_access = XENMEM_access_n;
> >> +else if ( r == 0 && w == 0 && x == 1 )
> >> +
>>> On 19.11.18 at 14:30, wrote:
>> > +/* Now transform our RWX values in a XENMEM_access_* constant. */
>>> +if ( r == 0 && w == 0 && x == 0 )
>>> +new_access = XENMEM_access_n;
>>> +else if ( r == 0 && w == 0 && x == 1 )
>>> +new_access = XENMEM_access_x;
>>> +els
>>> On 16.11.18 at 18:04, wrote:
> On Fri, Nov 16, 2018 at 10:06:36AM +, Alexandru Stefan ISAILA wrote:
>> @@ -377,6 +379,8 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn,
>> uint32_t nr,
>> p2m_access_t a;
>> unsigned long gfn_l;
>> long rc = 0;
>> +struct vcpu *v;
>> +/* Now transform our RWX values in a XENMEM_access_* constant. */
>> +if ( r == 0 && w == 0 && x == 0 )
>> +new_access = XENMEM_access_n;
>> +else if ( r == 0 && w == 0 && x == 1 )
>> +new_access = XENMEM_access_x;
>> +else if ( r == 0 && w == 1 && x == 0 )
>> +
On Fri, Nov 16, 2018 at 10:06:36AM +, Alexandru Stefan ISAILA wrote:
> A new mechanism has been added which is able to generically re-execute
> instructions, by temporarily granting permissions inside the EPT and
> re-executing the instruction with all other vcpus paused and with the
> monitor
A new mechanism has been added which is able to generically re-execute
instructions, by temporarily granting permissions inside the EPT and
re-executing the instruction with all other vcpus paused and with the
monitor trap flag set. The mechanism is re-entrant, meaning that is
capable of handling d
46 matches
Mail list logo
