From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: "Michael Kelley \(EOSG\)" <Michael.H.Kelley@microsoft.com>
Cc: "mhkelley58\@gmail.com" <mhkelley58@gmail.com>,
"gregkh\@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devel\@linuxdriverproject.org" <devel@linuxdriverproject.org>,
"olaf\@aepfle.de" <olaf@aepfle.de>,
"apw\@canonical.com" <apw@canonical.com>,
"jasowang\@redhat.com" <jasowang@redhat.com>,
"marcelo.cerri\@canonical.com" <marcelo.cerri@canonical.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
KY Srinivasan <kys@microsoft.com>
Subject: Re: [PATCH char-misc 1/1] Drivers: hv: vmbus: Make synic_initialized flag per-cpu
Date: Tue, 28 Aug 2018 22:59:47 +0200 [thread overview]
Message-ID: <87va7uxl4s.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <CY4PR21MB077375C31D9211486C328328DC0A0@CY4PR21MB0773.namprd21.prod.outlook.com> (Michael Kelley's message of "Tue, 28 Aug 2018 20:20:19 +0000")
"Michael Kelley (EOSG)" <Michael.H.Kelley@microsoft.com> writes:
> From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Wednesday, August 1, 2018 2:26 AM
>
>> > I was trying to decide if there are any arguments in favor of one
>> > approach vs. the other: a per-cpu flag in memory or checking
>> > the synic_control "enable" bit. Seems like a wash to me, in which
>> > case I have a slight preference for the per-cpu flag in memory vs.
>> > creating another function to return sctrl.enable. But I'm completely
>> > open to reasons why checking sctrl.enable is better.
>>
>> Just a few thoughts: reading MSR is definitely slower but we avoid
>> 'shadowing' the state, the reading is always correct. In case there's a
>> chance the SynIC will get disabled from host side we can only find this
>> out by doing MSR read. This is a purely theoretical possibility, I
>> believe, we can go ahead with this patch.
>
> Vitaly -- just to confirm: you are OK with the patch as is? (I'll
> check, but I may need to rebase on the latest code.)
Yes, feel free to use my R-b tag.
--
Vitaly
prev parent reply other threads:[~2018-08-28 20:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-31 2:34 [PATCH char-misc 1/1] Drivers: hv: vmbus: Make synic_initialized flag per-cpu mhkelley58
2018-07-31 11:19 ` Vitaly Kuznetsov
2018-08-01 5:47 ` Michael Kelley (EOSG)
2018-08-01 9:26 ` Vitaly Kuznetsov
2018-08-28 20:20 ` Michael Kelley (EOSG)
2018-08-28 20:59 ` Vitaly Kuznetsov [this message]
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=87va7uxl4s.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=Michael.H.Kelley@microsoft.com \
--cc=apw@canonical.com \
--cc=devel@linuxdriverproject.org \
--cc=gregkh@linuxfoundation.org \
--cc=jasowang@redhat.com \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.cerri@canonical.com \
--cc=mhkelley58@gmail.com \
--cc=olaf@aepfle.de \
--cc=sthemmin@microsoft.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.