From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 12/12] xen/events: use the FIFO-based ABI if available Date: Mon, 19 Aug 2013 12:55:08 +0100 Message-ID: <5212079C.8040304@citrix.com> References: <1376072121-17786-1-git-send-email-david.vrabel@citrix.com> <1376072121-17786-13-git-send-email-david.vrabel@citrix.com> <20130816174723.GJ12674@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130816174723.GJ12674@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Boris Ostrovsky , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 16/08/13 18:47, Wei Liu wrote: > On Fri, Aug 09, 2013 at 07:15:21PM +0100, David Vrabel wrote: >> From: David Vrabel >> >> If the hypervisor supports the FIFO-based ABI, enable it by >> initializing the control block for the boot VCPU and subsequent VCPUs >> as they are brought up. The event array is expanded as required when >> event ports are setup. >> >> This implementation has some known limitations: ... because I haven't implemented them yet. >> - Migration will not work as the control blocks or event arrays are >> not remapped by Xen at the destination. >> > > Is it possible to hook into xen_vcpu_restore to make it work? Yes, I think so. >> - The timer VIRQ which previously was treated as the highest priority >> event has the default priority. >> > > So what's missing from the series is a patch that allows kernel to > actually make use of the priority queues? IMHO it's not just about the > timer VIRQ. How do you plan to expose this interface to drivers? There will be Xen-specific xen_evtchn_set_priority() call. I don't think it can be usefully exposed to non-Xen-specific hardware drivers using PIRQs. I expect to use this for boosting the priority of the timer interrupt only. >> +static int __cpuinit fifo_cpu_notification(struct notifier_block *self, >> + unsigned long action, void *hcpu) >> +{ >> + int cpu = (long)hcpu; >> + int ret = 0; >> + >> + switch (action) { >> + case CPU_UP_PREPARE: >> + ret = fifo_init_control_block(cpu); >> + break; > > On the hypervisor side fifo_init_control_block would return -EINVAL if > this CPU has previous mapped control block. I need to look into this -- CPU hotplug is not something I really looked at or tried yet. Probably need to check if we have already done this. > Do you need to tear down the control block when you offline a CPU? (That > would mean another sub-op for the interface) None of the other per-VCPU is state appears to be cleaned up when a guest offlines a VCPU. e.g., there is a VCPUOP_register_vcpu_info but no VCPUOP_unregister_vcpu_info. David