On 2/21/23 21:46, juan.quint...@gmail.com wrote:
KVM developers conference call
Hi for today call:
Trivial stuff (less that 5mins each)
- should we record the sessions
- should we have the call every week.
We have on the backburner:
* TDX migration
Hi Juan,
Can I get 30 min (or more if no more other topics) in tomorrow's call to
continue the discussion on TDX live migration?
I also did some investigation on the previous comments about MigTD-to-MigTD
communication (remove socat), and have an update to discuss.
Thanks,
Wei
* VFIO/VPDA/Vhost migration
* Single binary qemu
The future of icount
Do we have an agenda for next weeks KVM call yet? If there is space I'd
like to take some time to discuss the future direction of icount.
Specifically I believe there might be some proposals for how we could
support icount with MTTCG worth discussing. From my point of view icount
provides too things:
- a sense of time vaguely related to execution rather than wall clock
- determinism
I would love to divorce the former from icount and punt it to plugins.
The plugin would be free to instrument as heavily or lightly as it sees
fit and provide its best guess as to guest time on demand. I wrote this
idea up as a card in Linaro's JIRA if anyone is interested:
https://linaro.atlassian.net/browse/QEMU-481
Being able to punt cost modelling and sense of time into plugins would
allow the core icount support to concentrate on determinism. Then any
attempt to enable icount for MTTCG would then have to ensure it stays
deterministic.
Richard and I have discussed the problem a few times and weren't sure it
was solvable but I'm totally open to hearing ideas on how to do it.
Fundamentally I think we would have to ensure any TB's doing IO would
have to execute in an exclusive context. The TCG code already has
mechanisms to ensure all IO is only done at the end of blocks so it
doesn't seem a huge leap to ensure we execute those blocks exclusively.
However there is still the problem of what to do about other pure
computation threads getting ahead or behind of the IO blocks on
subsequent runs.
KVM developers conference call
Tuesday 2023-02-21 ⋅ 15:00 – 16:00 (Central European Time - Madrid)
If you need call details, please contact me: quint...@redhat.com
Location
https://meet.jit.si/kvmcallmeeting
View map
<https://www.google.com/url?q=https%3A%2F%2Fmeet.jit.si%2Fkvmcallmeeting&sa=D&ust=1677419160000000&usg=AOvVaw0heTI2pkoiDPVZgv6XFxlS>
Guests
Philippe Mathieu-Daudé <mailto:f4...@amsat.org>
Joao Martins <mailto:joao.m.mart...@oracle.com>
quint...@redhat.com <mailto:quint...@redhat.com>
Meirav Dean <mailto:md...@redhat.com>
Felipe Franciosi <mailto:fel...@nutanix.com>
afaer...@suse.de <mailto:afaer...@suse.de>
bazu...@redhat.com <mailto:bazu...@redhat.com>
bbau...@redhat.com <mailto:bbau...@redhat.com>
c...@f00f.org <mailto:c...@f00f.org>
dustin.kirkl...@canonical.com <mailto:dustin.kirkl...@canonical.com>
ebl...@redhat.com <mailto:ebl...@redhat.com>
edgar.igles...@gmail.com <mailto:edgar.igles...@gmail.com>
Eric Northup <mailto:digitale...@google.com>
eric.au...@redhat.com <mailto:eric.au...@redhat.com>
i...@theiggy.com <mailto:i...@theiggy.com>
jan.kis...@web.de <mailto:jan.kis...@web.de>
jidong.x...@gmail.com <mailto:jidong.x...@gmail.com>
jjhe...@linux.vnet.ibm.com <mailto:jjhe...@linux.vnet.ibm.com>
m...@linux.vnet.ibm.com <mailto:m...@linux.vnet.ibm.com>
Peter Maydell <mailto:peter.mayd...@linaro.org>
richard.hender...@linaro.org <mailto:richard.hender...@linaro.org>
stefa...@gmail.com <mailto:stefa...@gmail.com>
Warner Losh <mailto:i...@bsdimp.com>
z....@139.com <mailto:z....@139.com>
zwu.ker...@gmail.com <mailto:zwu.ker...@gmail.com>
Jason Gunthorpe <mailto:j...@nvidia.com>
Neo Jia <mailto:c...@nvidia.com>
David Edmondson <mailto:david.edmond...@oracle.com>
Elena Ufimtseva <mailto:elena.ufimts...@oracle.com>
Konrad Wilk <mailto:konrad.w...@oracle.com>
a...@rev.ng <mailto:a...@rev.ng>
a...@rev.ng <mailto:a...@rev.ng>
Shameerali Kolothum Thodi <mailto:shameerali.kolothum.th...@huawei.com>
Wang, Wei W <mailto:wei.w.w...@intel.com>
Chao Peng <mailto:chao.p.p...@linux.intel.com>
kvm-devel <mailto:k...@vger.kernel.org>
qemu-devel@nongnu.org <mailto:qemu-devel@nongnu.org>
mbur...@qti.qualcomm.com <mailto:mbur...@qti.qualcomm.com>
