On 07/01/16 10:42, Ian Campbell wrote:
> On Wed, 2016-01-06 at 11:44 +, Andrew Cooper wrote:
>> All console logging is synchronous (to ensure that log messages have
>> escaped the VM before an action occurs) and by default, an HVM test will
>> use the qemu debug port, console_io hypercall, and
On 06/01/16 16:49, Jan Beulich wrote:
On 06.01.16 at 17:38, wrote:
>> On 06/01/16 16:31, Jan Beulich wrote:
>> On 06.01.16 at 15:44, wrote:
We did have an internal request for an HVM guest userspace netfront
driver to be able to use evntchnop calls directly.
>>> And this can't
>>> On 06.01.16 at 17:38, wrote:
> On 06/01/16 16:31, Jan Beulich wrote:
> On 06.01.16 at 15:44, wrote:
>>> We did have an internal request for an HVM guest userspace netfront
>>> driver to be able to use evntchnop calls directly.
>> And this can't be accomplished using the evtchn and/or priv
On 06/01/16 16:31, Jan Beulich wrote:
On 06.01.16 at 15:44, wrote:
>> We did have an internal request for an HVM guest userspace netfront
>> driver to be able to use evntchnop calls directly.
>
> And this can't be accomplished using the evtchn and/or privcmd
> drivers?
It can and should be
On 06/01/16 16:31, Jan Beulich wrote:
On 06.01.16 at 15:44, wrote:
>> We did have an internal request for an HVM guest userspace netfront
>> driver to be able to use evntchnop calls directly.
> And this can't be accomplished using the evtchn and/or privcmd
> drivers?
It can, and I don't beli
>>> On 06.01.16 at 15:44, wrote:
> We did have an internal request for an HVM guest userspace netfront
> driver to be able to use evntchnop calls directly.
And this can't be accomplished using the evtchn and/or privcmd
drivers?
Jan
___
Xen-devel mail
>>> On 06.01.16 at 17:20, wrote:
> On 06/01/16 16:09, Jan Beulich wrote:
>>
> For PV guests, I propose that userspace hypercalls get implemented with
> the int $0x82 path exclusively. i.e. enabling userspace hypercalls
> causes the hypercall page writing logic to consider the guest a
On 06/01/16 16:09, Jan Beulich wrote:
>
For PV guests, I propose that userspace hypercalls get implemented with
the int $0x82 path exclusively. i.e. enabling userspace hypercalls
causes the hypercall page writing logic to consider the guest a ring1
kernel, and the int $0x82 ent
>>> On 06.01.16 at 15:44, wrote:
> On 06/01/16 14:14, Jan Beulich wrote:
> On 06.01.16 at 12:44, wrote:
>>> The HVM ABI (for whatever reason) unilaterally fails
>>> a userspace hypercall with -EPERM, making it impossible for the kernel
>>> to trap-and-forward even it wanted to.
>> Perhaps jus
On 06/01/16 14:14, Jan Beulich wrote:
On 06.01.16 at 12:44, wrote:
>> The HVM ABI (for whatever reason) unilaterally fails
>> a userspace hypercall with -EPERM, making it impossible for the kernel
>> to trap-and-forward even it wanted to.
> Perhaps just to match PV behavior?
But it doesn't.
>>> On 06.01.16 at 12:44, wrote:
> The HVM ABI (for whatever reason) unilaterally fails
> a userspace hypercall with -EPERM, making it impossible for the kernel
> to trap-and-forward even it wanted to.
Perhaps just to match PV behavior?
> There are already scenarios under test where we cannot re
11 matches
Mail list logo
