[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4] x86/xen: Add support for HVMOP_set_evtchn_upcall_vector


  • To: Jane Malalane <jane.malalane@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 3 Nov 2022 16:41:19 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+hmyyJDgZX+O8LBzevAvj94q2P3zDTo/q2+m2tXPemk=; b=XFcFDn8QnunmAO9/gE7RphsZTpg53Ehe9v+y7PryenFag555n2ICKlsC/dtAAjDyLhJF2mE0s7uUWb/W20I2OtzBB8DmnujbIkuYkEN9Thc1/T5ljlomG5vFxWK7pEqg/E8W6gg9zg9cdF5XVkBABFRu6YacVMXkb2u4kzKN/KOr0IxsN2HeyU/ztYcTYQ0pFUK/r28stm6vJOJxqhqBAnXoiwxxfqCQJtsI8GvCdtLisOi9TEzALvq17CDQGQsstgbTXfKHdLQOGCuRdWop9ApFUP9MnaQKSufWHYjs5VN/R4jKF8+5pa2eeU5/8h09IpVuvPlSm7IhIlELTID2Ug==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TTTlEDKHK6F7PLDfjtLtgiQIYTwMKB2NK3XLzkVUOp3QG6M4b8IXAR0a6DqUfxvlFu85OadpgCWor8a7FJzb2JZ0tga1s+xNdP+sAiZrUoGarQda3HGB39LDA1JwgbG4ZA1G+6aTqqGoH0zOpKvW7CnVS5/0/+JiSI1UqCYSW546on7sh8NXYyVfDzehT+82DwecDR/I64PMGulv5lndbpwQE4XnJLNgHnJ0z0N7odFgOYmQrqbZ3dNjPTsrHvehuvASj8HWuIy2jOvoMdPrizQcFtXutq2vJpKQIxX6B9kW0qKCiBLG024TcfFhZpHREKoYDK8qD9DrScSR/PmyzA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Juergen Gross <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, x86@xxxxxxxxxx, "H. Peter Anvin" <hpa@xxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>, Maximilian Heyne <mheyne@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, LKML <linux-kernel@xxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 03 Nov 2022 15:41:33 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03.11.2022 14:38, Jan Beulich wrote:
> On 29.07.2022 09:04, Jane Malalane wrote:
>> @@ -125,6 +130,9 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_xen_hvm_callback)
>>  {
>>      struct pt_regs *old_regs = set_irq_regs(regs);
>>  
>> +    if (xen_percpu_upcall)
>> +            ack_APIC_irq();
>> +
>>      inc_irq_stat(irq_hv_callback_count);
>>  
>>      xen_hvm_evtchn_do_upcall();
>> @@ -168,6 +176,15 @@ static int xen_cpu_up_prepare_hvm(unsigned int cpu)
>>      if (!xen_have_vector_callback)
>>              return 0;
>>  
>> +    if (xen_percpu_upcall) {
>> +            rc = xen_set_upcall_vector(cpu);
> 
> From all I can tell at least for APs this happens before setup_local_apic().
> With there being APIC interaction in this operation mode, as seen e.g. in
> the earlier hunk above, I think this is logically wrong. And it leads to
> apic_pending_intr_clear() issuing its warning: The vector registration, as
> an intentional side effect, marks the vector as pending. Unless IRQs were
> enabled at any point between the registration and the check, there's
> simply no way for the corresponding IRR bit to be dealt with (by
> propagating to ISR when the interrupt is delivered, and then being cleared
> from ISR by EOI).

With Roger's help I now have a pointer to osstest also exposing the issue:

http://logs.test-lab.xenproject.org/osstest/logs/174592/test-amd64-amd64-xl-pvhv2-intel/huxelrebe0---var-log-xen-console-guest-debian.guest.osstest.log.gz

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.