On Tue, 2022-12-20 at 17:29 +, David Woodhouse wrote:
> On 20 December 2022 17:25:31 GMT, Paul Durrant wrote:
> > On 20/12/2022 16:27, David Woodhouse wrote:
> > >
> > >
> > > On 20 December 2022 13:56:39 GMT, Paul Durrant
> > > wrote:
> > > > The callback via is essentially just another li
On 21 December 2022 09:37:36 GMT, Paul Durrant wrote:
>On 21/12/2022 01:41, David Woodhouse wrote:
+ exit->u.hcall.result = err;
>>>
>>> This is a bit on the ugly side isn't it? Why not return the err and have
>>> kvm_xen_hcall_hvm_op() deal with passing it back?
>>
>> Because 'return
On 21/12/2022 01:41, David Woodhouse wrote:
On Mon, 2022-12-12 at 16:16 +, Paul Durrant wrote:
@@ -287,24 +289,53 @@ static bool kvm_xen_hcall_memory_op(struct kvm_xen_exit
*exit,
return true;
}
+static int handle_set_param(struct kvm_xen_exit *exit, X86CPU *cpu,
+
On Mon, 2022-12-12 at 16:16 +, Paul Durrant wrote:
>
> > @@ -287,24 +289,53 @@ static bool kvm_xen_hcall_memory_op(struct
> > kvm_xen_exit *exit,
> > return true;
> > }
> >
> > +static int handle_set_param(struct kvm_xen_exit *exit, X86CPU *cpu,
> > + uin
On 20/12/2022 16:27, David Woodhouse wrote:
On 20 December 2022 13:56:39 GMT, Paul Durrant wrote:
The callback via is essentially just another line interrupt but its assertion
is closely coupled with the vcpu upcall_pending bit. Because that is being
dealt with in-kernel then the via should
On 20 December 2022 17:25:31 GMT, Paul Durrant wrote:
>On 20/12/2022 16:27, David Woodhouse wrote:
>>
>>
>> On 20 December 2022 13:56:39 GMT, Paul Durrant wrote:
>>> The callback via is essentially just another line interrupt but its
>>> assertion is closely coupled with the vcpu upcall_pen
On 20 December 2022 13:56:39 GMT, Paul Durrant wrote:
>The callback via is essentially just another line interrupt but its assertion
>is closely coupled with the vcpu upcall_pending bit. Because that is being
>dealt with in-kernel then the via should be dealt with in-kernel, right?
Not right
On 15/12/2022 20:54, David Woodhouse wrote:
On Mon, 2022-12-12 at 16:39 +, Paul Durrant wrote:
On 12/12/2022 16:26, David Woodhouse wrote:
On Mon, 2022-12-12 at 16:16 +, Paul Durrant wrote:
On 09/12/2022 09:56, David Woodhouse wrote:
From: Ankur Arora
The HVM_PARAM_CALLBACK_IRQ param
On Mon, 2022-12-12 at 16:39 +, Paul Durrant wrote:
> On 12/12/2022 16:26, David Woodhouse wrote:
> > On Mon, 2022-12-12 at 16:16 +, Paul Durrant wrote:
> > > On 09/12/2022 09:56, David Woodhouse wrote:
> > > > From: Ankur Arora
> > > > The HVM_PARAM_CALLBACK_IRQ parameter controls the syst
On 12/12/2022 16:26, David Woodhouse wrote:
On Mon, 2022-12-12 at 16:16 +, Paul Durrant wrote:
On 09/12/2022 09:56, David Woodhouse wrote:
From: Ankur Arora
The HVM_PARAM_CALLBACK_IRQ parameter controls the system-wide event
channel upcall method. The vector support is handled by KVM inte
On Mon, 2022-12-12 at 16:16 +, Paul Durrant wrote:
> On 09/12/2022 09:56, David Woodhouse wrote:
> > From: Ankur Arora
> > The HVM_PARAM_CALLBACK_IRQ parameter controls the system-wide event
> > channel upcall method. The vector support is handled by KVM internally,
> > when the evtchn_upcall
On 09/12/2022 09:56, David Woodhouse wrote:
From: Ankur Arora
The HVM_PARAM_CALLBACK_IRQ parameter controls the system-wide event
channel upcall method. The vector support is handled by KVM internally,
when the evtchn_upcall_pending field in the vcpu_info is set.
The GSI and PCI_INTX delivery
From: Ankur Arora
The HVM_PARAM_CALLBACK_IRQ parameter controls the system-wide event
channel upcall method. The vector support is handled by KVM internally,
when the evtchn_upcall_pending field in the vcpu_info is set.
The GSI and PCI_INTX delivery methods are not supported. yet; those
need to
13 matches
Mail list logo
