All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH] xen/x86: fix PV trap handling on secondary processors
Date: Fri, 17 Sep 2021 09:24:34 +0200	[thread overview]
Message-ID: <35835650-bbbb-7dbd-061b-693f39f9453e@suse.com> (raw)
In-Reply-To: <2c4549c8-bdeb-3584-95c4-7076b7cf79bb@suse.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 1383 bytes --]

On 17.09.21 08:50, Jan Beulich wrote:
> On 17.09.2021 08:47, Juergen Gross wrote:
>> On 17.09.21 08:40, Jan Beulich wrote:
>>> On 17.09.2021 03:34, Boris Ostrovsky wrote:
>>>>
>>>> On 9/16/21 11:04 AM, Jan Beulich wrote:
>>>>>    {
>>>>>    	const struct desc_ptr *desc = this_cpu_ptr(&idt_desc);
>>>>> +	unsigned i, count = (desc->size + 1) / sizeof(gate_desc);
>>>>>    
>>>>> -	xen_convert_trap_info(desc, traps);
>>>>
>>>>
>>>> Can you instead add a boolean parameter to xen_convert_trap_info() to indicate whether to skip empty entries? That will avoid (almost) duplicating the code.
>>>
>>> I can, sure, but I specifically didn't, as the result is going to be less
>>> readable imo. Instead I was considering to fold xen_convert_trap_info()
>>> into its only remaining caller. Yet if you're convinced adding the
>>> parameter is the way to do, I will go that route. But please confirm.
>>
>> I don't think the result will be very hard to read. All you need is the
>> new parameter and extending the if statement in xen_convert_trap_info()
>> to increment out always if no entry is to be skipped.
> 
> And skip writing the sentinel.

Maybe it would be even better then to let xen_convert_trap_info() return
the number of entries written and to write the sentinel in
xen_load_idt() instead, as this is the only place where it is needed.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

  reply	other threads:[~2021-09-17  7:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16 15:04 [PATCH] xen/x86: fix PV trap handling on secondary processors Jan Beulich
2021-09-17  1:34 ` Boris Ostrovsky
2021-09-17  6:40   ` Jan Beulich
2021-09-17  6:47     ` Juergen Gross
2021-09-17  6:50       ` Jan Beulich
2021-09-17  7:24         ` Juergen Gross [this message]
2021-09-17 17:50           ` Boris Ostrovsky

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=35835650-bbbb-7dbd-061b-693f39f9453e@suse.com \
    --to=jgross@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=jbeulich@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /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.