All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@qumranet.com>
To: Ben-Ami Yassour <benami@il.ibm.com>
Cc: amit.shah@qumranet.com, kvm@vger.kernel.org,
	Muli Ben-Yehuda <muli@il.ibm.com>,
	weidong.han@intel.com, anthony@codemonkey.ws
Subject: Re: [PATCH 3/8] KVM: Handle device assignment to guests
Date: Thu, 17 Jul 2008 12:50:06 +0300	[thread overview]
Message-ID: <487F15CE.5050204@qumranet.com> (raw)
In-Reply-To: <1216287258.31546.337.camel@cluwyn.haifa.ibm.com>

Ben-Ami Yassour wrote:
> On Wed, 2008-07-16 at 18:04 +0300, Avi Kivity wrote:
>   
>> Ben-Ami Yassour wrote:
>>     
>>> +/* Stores information for identifying host PCI devices assigned to the
>>> + * guest: this is used in the host kernel and in the userspace.
>>> + */
>>> +struct kvm_pci_pt_info {
>>> +	unsigned char busnr;
>>> +	unsigned int devfn;
>>> +	__u32 irq;
>>> +};
>>>   
>>>       
>> Badly aligned.  Please use __u32 for all fields, and add a __u32 padding 
>> field at the end so we have the same ABI for i386 and x86_64.
>>
>> Some pci devices support more than one irq.  Should we make irq an 
>> array?  Alternatively, decouple irq assignment from pci information
>> and 
>> let userspace handle everything.  This lets us assign non-pci devices 
>> (like serial ports, etc.).
>>     
> Can we limit the first version to single irq devices, and handle this
> after the merge?
>
>   

Yes.  But we need to get at least the userspace interface right (and 
perhaps only partially implement it).  Breaking the userspace interface 
later is possible, but I'd rather avoid it.

>>>   * ioctls for vcpu fds
>>> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
>>> index 8ce93c7..0b5bc40 100644
>>> --- a/virt/kvm/ioapic.c
>>> +++ b/virt/kvm/ioapic.c
>>> @@ -288,13 +288,22 @@ void kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int level)
>>>  static void __kvm_ioapic_update_eoi(struct kvm_ioapic *ioapic, int gsi)
>>>  {
>>>  	union ioapic_redir_entry *ent;
>>> +	struct kvm_pci_pt_dev_list *match;
>>> +	unsigned long flags;
>>>  
>>>  	ent = &ioapic->redirtbl[gsi];
>>>  	ASSERT(ent->fields.trig_mode == IOAPIC_LEVEL_TRIG);
>>>  
>>>  	ent->fields.remote_irr = 0;
>>> -	if (!ent->fields.mask && (ioapic->irr & (1 << gsi)))
>>> -		ioapic_service(ioapic, gsi);
>>> +
>>> +	read_lock_irqsave(&kvm_pci_pt_lock, flags);
>>> +	match = kvm_find_pci_pt_dev(&ioapic->kvm->arch.pci_pt_dev_head, NULL,
>>> +				    gsi, KVM_PT_SOURCE_IRQ_ACK);
>>> +	read_unlock_irqrestore(&kvm_pci_pt_lock, flags);
>>> +	if (!match) {
>>> +		if (!ent->fields.mask && (ioapic->irr & (1 << gsi)))
>>> +			ioapic_service(ioapic, gsi);
>>> +	}
>>>   
>>>       
>> What's device assignment code doing in the ioapic?  This should be done 
>> through the notifier (if it needs to return a value, great).
>>
>>     
>
> This purpose of this code is to avoid the call to ioapic_service for
> assigned devices, because it is not required and causes a double
> injection of the interrupt.
>
> Can you please explain why as part of eoi we inject a new interrupt?
>   

If a level triggered interrupt remains active after the eoi, the ioapic 
has to inject it.  This is used to support shared interrupts, or when 
the device has re-raised the line by the time the ack arrives.

I don't see why it should behave differently for assigned devices.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2008-07-17  9:50 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-16 13:16 PCI passthrough with VT-d - native performance Ben-Ami Yassour
2008-07-16 13:16 ` [PATCH 1/8] KVM: Introduce a callback routine for IOAPIC ack handling Ben-Ami Yassour
2008-07-16 13:16   ` [PATCH 2/8] KVM: Introduce a callback routine for PIC " Ben-Ami Yassour
2008-07-16 13:17     ` [PATCH 3/8] KVM: Handle device assignment to guests Ben-Ami Yassour
2008-07-16 13:17       ` [PATCH 4/8] KVM: PCIPT: fix interrupt handling Ben-Ami Yassour
2008-07-16 13:17         ` [PATCH 5/8] KVM: PCIPT: change order of device release Ben-Ami Yassour
2008-07-16 13:17           ` [PATCH 6/8] VT-d: changes to support KVM Ben-Ami Yassour
2008-07-16 13:17             ` [PATCH 7/8] KVM: PCIPT: VT-d support Ben-Ami Yassour
2008-07-16 13:17               ` [PATCH 8/8] KVM: PCIPT: VT-d: dont map mmio memory slots Ben-Ami Yassour
2008-07-16 13:21                 ` PCI passthrough with VT-d - native performance Ben-Ami Yassour
2008-07-16 13:21                   ` [PATCH 1/2] KVM/userspace: Support for assigning PCI devices to guest Ben-Ami Yassour
2008-07-16 13:21                     ` [PATCH 2/2] PCIPT: direct mmio Ben-Ami Yassour
2008-07-17  7:52                     ` [PATCH 1/2] KVM/userspace: Support for assigning PCI devices to guest Han, Weidong
2008-07-22 12:28                       ` Ben-Ami Yassour
2008-07-22 12:44                         ` [PATCH 1/2] KVM/userspace: Support for assigning PCI devicesto guest Han, Weidong
2008-07-16 15:06           ` [PATCH 5/8] KVM: PCIPT: change order of device release Avi Kivity
2008-07-16 15:06         ` [PATCH 4/8] KVM: PCIPT: fix interrupt handling Avi Kivity
2008-07-23 13:37         ` Amit Shah
2008-07-24 11:28           ` Ben-Ami Yassour
2008-07-24 13:31             ` Amit Shah
2008-07-24 14:24               ` Ben-Ami Yassour
2008-07-16 15:04       ` [PATCH 3/8] KVM: Handle device assignment to guests Avi Kivity
2008-07-17  2:09         ` Han, Weidong
2008-07-17  2:29           ` Yang, Sheng
2008-07-17  6:02           ` Avi Kivity
2008-07-17  8:23             ` Ben-Ami Yassour
2008-07-17  8:31               ` Avi Kivity
2008-07-17 18:01                 ` Ben-Ami Yassour
2008-07-17 18:07                   ` Avi Kivity
2008-07-17  9:34         ` Ben-Ami Yassour
2008-07-17  9:50           ` Avi Kivity [this message]
2008-07-17 17:40             ` Ben-Ami Yassour
2008-07-17 18:04               ` Avi Kivity
2008-07-16 14:36 ` PCI passthrough with VT-d - native performance Avi Kivity
2008-07-16 15:18   ` Ben-Ami Yassour
2008-07-16 15:22     ` Avi Kivity
2008-07-16 15:23     ` Anthony Liguori
2008-07-16 16:13       ` Ben-Ami Yassour
2008-07-16 16:57         ` Avi Kivity
2008-07-17  6:24           ` Ben-Ami Yassour
2008-07-17  3:20       ` Han, Weidong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=487F15CE.5050204@qumranet.com \
    --to=avi@qumranet.com \
    --cc=amit.shah@qumranet.com \
    --cc=anthony@codemonkey.ws \
    --cc=benami@il.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=muli@il.ibm.com \
    --cc=weidong.han@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.