Date:   Mon, 22 May 2023 15:25:08 +0800
From:   Chao Peng <chao.p.peng@...ux.intel.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     kvm@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
        Sagi Shahar <sagis@...gle.com>,
        Erdem Aktas <erdemaktas@...gle.com>,
        Anish Ghulati <aghulati@...gle.com>,
        Oliver Upton <oliver.upton@...ux.dev>,
        James Houghton <jthoughton@...gle.com>,
        Anish Moorthy <amoorthy@...gle.com>,
        Ben Gardon <bgardon@...gle.com>,
        David Matlack <dmatlack@...gle.com>,
        Ricardo Koller <ricarkol@...gle.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Aaron Lewis <aaronlewis@...gle.com>,
        Ashish Kalra <ashish.kalra@....com>,
        Babu Moger <babu.moger@....com>, Chao Gao <chao.gao@...el.com>,
        Chenyi Qiang <chenyi.qiang@...el.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Emanuele Giuseppe Esposito <eesposit@...hat.com>,
        Gavin Shan <gshan@...hat.com>,
        Guang Zeng <guang.zeng@...el.com>,
        Hou Wenlong <houwenlong.hwl@...group.com>,
        Jiaxi Chen <jiaxi.chen@...ux.intel.com>,
        Jim Mattson <jmattson@...gle.com>,
        Jing Liu <jing2.liu@...el.com>,
        Junaid Shahid <junaids@...gle.com>,
        Kai Huang <kai.huang@...el.com>,
        Leonardo Bras <leobras@...hat.com>,
        Like Xu <like.xu.linux@...il.com>,
        Li RongQing <lirongqing@...du.com>,
        "Maciej S . Szmigiero" <maciej.szmigiero@...cle.com>,
        Maxim Levitsky <mlevitsk@...hat.com>,
        Michael Roth <michael.roth@....com>,
        Michal Luczaj <mhal@...x.co>,
        Mingwei Zhang <mizhang@...gle.com>,
        Nikunj A Dadhania <nikunj@....com>,
        Paul Durrant <pdurrant@...zon.com>,
        Peng Hao <flyingpenghao@...il.com>,
        Peter Gonda <pgonda@...gle.com>, Peter Xu <peterx@...hat.com>,
        Robert Hoo <robert.hu@...ux.intel.com>,
        Suravee Suthikulpanit <suravee.suthikulpanit@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Vipin Sharma <vipinsh@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Wei Wang <wei.w.wang@...el.com>,
        Xiaoyao Li <xiaoyao.li@...el.com>,
        Yu Zhang <yu.c.zhang@...ux.intel.com>,
        Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
        David Hildenbrand <david@...hat.com>,
        Fuad Tabba <tabba@...gle.com>,
        Isaku Yamahata <isaku.yamahata@...il.com>,
        Qinglan Xiang <qinglan.xiang@...el.com>,
        Kai Svahn <kai.svahn@...el.com>,
        Margarita Maroto <margarita.maroto@...el.com>,
        Anil Keshavamurthy <anil.s.keshavamurthy@...el.com>,
        Nagareddy Reddy <nspreddy@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE / RFC] Periodic Upstream Call for KVM

On Fri, May 12, 2023 at 04:10:27PM -0700, Sean Christopherson wrote:
> I am "officially" announcing a Periodic Upstream Call for KVM, a.k.a. PUCK.
> The intent of the PUCK is to provide a vehicle for having "in-person" technical
> discussions of features, designs, problems, etc. that are cumbersome to discuss
> asynchronously on-list, e.g. because something is too complex, too large, etc.

Yes, although on-list discussion is still the primary channel, a call is
a nice supplement for all relevant people on a large, complex topic to
achieve quick alignment. For people not able to attend the call, the
meeting recordings/minutes can be posted for them.

> 
> Exact details are TBD, and obviously can be adapted as needed.  Proposal:
> 
>   Frequency: Weekly
>   Time:      Wednesday, 6:00am Pacific Time
>   Duration:  60 minutes
>   Software:  ???
> 
> My thinking for weekly versus fortnightly (every other week) is that we can always
> cancel meetings if there are no agenda items, and bump down to fortnightly if we
> are constantly canceling.  On the flip side, if we go with fortnightly, it'd be
> more difficult to clear the backlog if PUCK gets booked out multiple sessions, and
> PUCK would be less useful for discussing urgent issues.
> 
> As for the time, 6am Pacific Time was the least awful (and still quite awful IMO)
> time I could find that gives the majority of the community a reasonable chance of
> attending.  I know we have developers in at least the below time zones (and probably
> more, though I don't think anyone works from Hawaii, and if someone does work from
> Hawaii then they have nothing to complain about :-) ).
> 
>   PT   (6am)
>   MT   (7am)
>   CT   (8am)
>   ET   (9am)
>   WET  (2pm)
>   CET  (3pm)
>   EET  (4pm)
>   EST  (5pm)
>   CST  (9pm)
>   NZST (1am)

This looks good, 9pm is not too late for PRC people.

> 
> The obvious alternative would be to invert the schedule and have the sync be in
> the evening/night for Pacific Time, but to get 6am for ARM folks, we end up with:
> 
>   PT   (10pm)
>   MT   (11pm)
>   CT   (12pm)
>   ET   (1am)
>   WET  (6am)
>   CET  (7am)
>   EET  (8am)
>   EST  (9am)
>   CST  (1pm)
>   NZST (5pm)
> 
> which is quite unreasonable for pretty much everyone based in the US.  Earlier
> than 6am for WET is likewise unreasonable and will result in people not attending.
> 9pm for China is also unreasonable, but I hope that it's not completely ridiculous
> and is doable enough that people can at least attend on an as-needed basis.  Sorry
> Kai, as the sole representative from New Zealand, you get hosed :-(
> 
> Wednesday because holidays and (short) vacations most often land at the beginning
> and end of the week.
> 
> 60 minutes because I'm not waking up at dawn for anything less, and anything
> more will likely have dimishing returns, especially for folks on the edges of
> the time zone table.
> 
> Lastly, the big unknown is which video communication software to use.  My default
> is obviously Google Meet, but I've been told that Meet is unusable in some
> countries. :-/  My only requirements (beyond basic, obvious functionality) are
> that (a) there's a web interface (no install required) and that (b) the calls can
> be recorded.

Google Meet should work for me, but may not for every (PRC) people.
Besides no installation, if no registration would be even better ;)
Maybe we can run with Google Meet for the first session(s) if you
havn't get one in your mind, it's not too hard to switch to alternative
at a later time right?

> 
> To kick things off, I am leaning toward a "launch" date of May 24th (Pacific),
> with KVM guest private mem (a.k.a. UPM) as the first topic.

Thanks for driving this, yes for UPM I would definitely join.

Chao
> 
> Please chime in with thoughts and ideas!
> 
> 
> P.S. This is an open invite, feel free to forward at will.  The Cc list is by no
> means intended to be definitive.

Powered by blists - more mailing lists