Re: [Xen-devel] [PATCH 12/12] xen/events: use the FIFO-based ABI if available

[David Vrabel <david.vrabel@xxxxxxxxxx>]

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 <david.vrabel@xxxxxxxxxx>
>>
>> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel