On Tue, 2021-01-05 at 12:11 +, Joao Martins wrote:
> On 1/1/21 2:33 PM, David Woodhouse wrote:
> > What it does actually mean in the short term is that as I update your
> > KVM_IRQ_ROUTING_XEN_EVTCHN support, I probably *won't* bother to add a
> > 'priority' field to struct kvm_irq_routing_xen_
On 1/1/21 2:33 PM, David Woodhouse wrote:
> On Wed, 2020-12-02 at 18:34 +, Joao Martins wrote:
>>> But if the kernel is going to short-circuit the IPIs and VIRQs, then
>>> it's already going to have to handle the evtchn_pending/evtchn_mask
>>> bitmaps, and actually injecting interrupts.
>>>
>>
On Wed, 2020-12-02 at 18:34 +, Joao Martins wrote:
> > But if the kernel is going to short-circuit the IPIs and VIRQs, then
> > it's already going to have to handle the evtchn_pending/evtchn_mask
> > bitmaps, and actually injecting interrupts.
> >
>
> Right. I was trying to point that out in
On 12/9/20 3:41 PM, David Woodhouse wrote:
> On 9 December 2020 13:26:55 GMT, Joao Martins
> wrote:
>> On 12/9/20 11:39 AM, David Woodhouse wrote:
>>> As far as I can tell, Xen's hvm_vcpu_has_pending_irq() will still
>>> return the domain-wide vector in preference to the one in the LAPIC,
>> if
>
On 9 December 2020 13:26:55 GMT, Joao Martins wrote:
>On 12/9/20 11:39 AM, David Woodhouse wrote:
>> On Wed, 2020-12-09 at 10:51 +, Joao Martins wrote:
>>> Isn't this what the first half of this patch was doing initially
>(minus the
>>> irq routing) ? Looks really similar:
>>>
>>>
>https://
On 12/9/20 11:39 AM, David Woodhouse wrote:
> On Wed, 2020-12-09 at 10:51 +, Joao Martins wrote:
>> Isn't this what the first half of this patch was doing initially (minus the
>> irq routing) ? Looks really similar:
>>
>> https://lore.kernel.org/kvm/20190220201609.28290-11-joao.m.mart...@oracle
On Wed, 2020-12-09 at 10:51 +, Joao Martins wrote:
> Isn't this what the first half of this patch was doing initially (minus the
> irq routing) ? Looks really similar:
>
> https://lore.kernel.org/kvm/20190220201609.28290-11-joao.m.mart...@oracle.com/
Absolutely! This thread is in reply to you
On 12/9/20 10:27 AM, David Woodhouse wrote:
> On Tue, 2020-12-08 at 22:35 -0800, Ankur Arora wrote:
>>> It looks like Linux doesn't use the per-vCPU upcall vector that you
>>> called 'KVM_XEN_CALLBACK_VIA_EVTCHN'. So I'm delivering interrupts via
>>> KVM_INTERRUPT as if they were ExtINT
>>>
On Tue, 2020-12-08 at 22:35 -0800, Ankur Arora wrote:
> > It looks like Linux doesn't use the per-vCPU upcall vector that you
> > called 'KVM_XEN_CALLBACK_VIA_EVTCHN'. So I'm delivering interrupts via
> > KVM_INTERRUPT as if they were ExtINT
> >
> > ... except I'm not. Because the kernel reall
On 2020-12-08 8:08 a.m., David Woodhouse wrote:
On Wed, 2020-12-02 at 19:02 +, David Woodhouse wrote:
I feel we could just accommodate it as subtype in
KVM_XEN_ATTR_TYPE_CALLBACK_VIA.
Don't see the adavantage in having another xen attr type.
Yeah, fair enough.
But kinda have mixed fee
On Wed, 2020-12-02 at 19:02 +, David Woodhouse wrote:
>
> > I feel we could just accommodate it as subtype in
> > KVM_XEN_ATTR_TYPE_CALLBACK_VIA.
> > Don't see the adavantage in having another xen attr type.
>
> Yeah, fair enough.
>
> > But kinda have mixed feelings in having kernel handlin
On 2020-12-02 11:02 a.m., David Woodhouse wrote:
On Wed, 2020-12-02 at 18:34 +, Joao Martins wrote:
On 12/2/20 4:47 PM, David Woodhouse wrote:
On Wed, 2020-12-02 at 13:12 +, Joao Martins wrote:
On 12/2/20 11:17 AM, David Woodhouse wrote:
I might be more inclined to go for a model wher
On Wed, 2020-12-02 at 20:12 +, Joao Martins wrote:
> > I'll do some more experiments and
> > see what I can get working, and what it looks like.
> >
> > I'm focusing on making the shinfo stuff all use kvm_map_gfn() first.
> >
>
> I was chatting with Ankur, and we can't fully 100% remember wh
On 12/2/20 7:02 PM, David Woodhouse wrote:
> On Wed, 2020-12-02 at 18:34 +, Joao Martins wrote:
>> On 12/2/20 4:47 PM, David Woodhouse wrote:
>>> On Wed, 2020-12-02 at 13:12 +, Joao Martins wrote:
On 12/2/20 11:17 AM, David Woodhouse wrote:
>>> For the VMM
>>> API I think we should fol
On Wed, 2020-12-02 at 18:34 +, Joao Martins wrote:
> On 12/2/20 4:47 PM, David Woodhouse wrote:
> > On Wed, 2020-12-02 at 13:12 +, Joao Martins wrote:
> > > On 12/2/20 11:17 AM, David Woodhouse wrote:
> > > > I might be more inclined to go for a model where the kernel handles the
> > > > ev
On 12/2/20 4:47 PM, David Woodhouse wrote:
> On Wed, 2020-12-02 at 13:12 +, Joao Martins wrote:
>> On 12/2/20 11:17 AM, David Woodhouse wrote:
>>> I might be more inclined to go for a model where the kernel handles the
>>> evtchn_pending/evtchn_mask for us. What would go into the irq routing
>>
On Wed, 2020-12-02 at 13:12 +, Joao Martins wrote:
> On 12/2/20 11:17 AM, David Woodhouse wrote:
> > I might be more inclined to go for a model where the kernel handles the
> > evtchn_pending/evtchn_mask for us. What would go into the irq routing
> > table is { vcpu, port# } which get passed to
On 12/2/20 11:17 AM, David Woodhouse wrote:
> On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote:
>> @@ -176,6 +177,9 @@ int kvm_arch_set_irq_inatomic(struct
>> kvm_kernel_irq_routing_entry *e,
>> int r;
>>
>> switch (e->type) {
>> + case KVM_IRQ_ROUTING_XEN_EVTCHN:
>> +
On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote:
> @@ -176,6 +177,9 @@ int kvm_arch_set_irq_inatomic(struct
> kvm_kernel_irq_routing_entry *e,
> int r;
>
> switch (e->type) {
> + case KVM_IRQ_ROUTING_XEN_EVTCHN:
> + return kvm_xen_set_evtchn(e, kvm, irq_
From: Ankur Arora
Add support for HVM_PARAM_CALLBACK_VIA_TYPE_VECTOR and
HVM_PARAM_CALLBACK_VIA_TYPE_EVTCHN upcall. Some Xen upcall variants do
not have an EOI for received upcalls. We handle that by directly
injecting the interrupt in the VMCS instead of going through the
LAPIC.
Note that the r
20 matches
Mail list logo
