This event has been cancelled.
Title: Project Stratos Sync
Discuss the latest Project Stratos devlopments.
When: Thu 30 Jul 2020 3pm – 3:50pm United Kingdom Time
Joining info: Join with Google Meet
https://meet.google.com/uak-yrcj-tyd
Join by phone
(GB) +44 20 3956 3214 (PIN: 706606273)
More phone numbers: https://tel.meet/uak-yrcj-tyd?pin=4387074781142&hs=0
Calendar: stratos-dev(a)op-lists.linaro.org
Who:
* Mike Holmes- organiser
* souvik.chakravarty(a)arm.com
* Joakim Bech
* Anmar Oueja
* sreemeno(a)qti.qualcomm.com
* Tom Gall
* pratikp(a)quicinc.com
* Sumit Semwal
* David Brazdil
* François Ozog
* ilias.apalodimas(a)linaro.org
* Bill Fletcher
* svaddagi(a)qti.qualcomm.com
* David Rusling
* Don Harbin
* shashi.mallela(a)linaro.org
* atouzni(a)qti.qualcomm.com
* randy.linnell(a)linaro.org
* Sandeep Patil
* matt.spencer(a)arm.com
* ruchika.gupta(a)linaro.org
* victor.duan(a)linaro.org
* adelva(a)google.com
* Mathieu Poirier
* bogdan.costinescu(a)nxp.com
* tsoni(a)quicinc.com
* srinivas.kalaga(a)huawei.com
* bogdan.vlad(a)nxp.com
* peng.fan(a)nxp.com
* stratos-dev(a)op-lists.linaro.org
Attachments:
* Virtualization infrastructure enhancements Agenda -
https://docs.google.com/document/d/1R4nlRrMvZzmvTFWvL-lobJr6J3TGNxBBlar_Ls7…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
stratos-dev(a)op-lists.linaro.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively, you can sign up for a Google Account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organiser and be added to the guest list, invite others regardless of
their own invitation status or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
I have a clash at 2pm, but may be able to attend some of the meetings if we move it to 2pm.
/Matt
________________________________
From: Stratos-dev <stratos-dev-bounces(a)op-lists.linaro.org> on behalf of Tom Gall via Stratos-dev <stratos-dev(a)op-lists.linaro.org>
Sent: 27 July 2020 15:57
To: Mike Holmes <mike.holmes(a)linaro.org>
Cc: Ruchika Gupta <ruchika.gupta(a)linaro.org>; stratos-dev(a)op-lists.linaro.org <stratos-dev(a)op-lists.linaro.org>
Subject: Re: [Stratos-dev] Stratos Project Sync call
> On Jul 27, 2020, at 8:48 AM, Mike Holmes via Stratos-dev <stratos-dev(a)op-lists.linaro.org> wrote:
>
> All
>
> We have been using the 3pm GMT slot on Thursdays every other week for the
> sync call, unfortunately this repeatedly clashes with an all hands Linaro
> call, as it does this week
>
> I propose we make it the 2.00pm GMT Thursday slot every other week, any
> other suggestions ?
Or perhaps flip it around. Does anyone disagree with moving it to 1400 GMT?
Certainly sounds good. :-)
> Mike
>
> --
> Mike Holmes | Director, Foundation Technologies, Linaro
> Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
> "Work should be fun and collaborative, the rest follows"
> --
> Stratos-dev mailing list
> Stratos-dev(a)op-lists.linaro.org
> https://op-lists.linaro.org/mailman/listinfo/stratos-dev
--
Stratos-dev mailing list
Stratos-dev(a)op-lists.linaro.org
https://op-lists.linaro.org/mailman/listinfo/stratos-dev
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> On Jul 27, 2020, at 8:48 AM, Mike Holmes via Stratos-dev <stratos-dev(a)op-lists.linaro.org> wrote:
>
> All
>
> We have been using the 3pm GMT slot on Thursdays every other week for the
> sync call, unfortunately this repeatedly clashes with an all hands Linaro
> call, as it does this week
>
> I propose we make it the 2.00pm GMT Thursday slot every other week, any
> other suggestions ?
Or perhaps flip it around. Does anyone disagree with moving it to 1400 GMT?
Certainly sounds good. :-)
> Mike
>
> --
> Mike Holmes | Director, Foundation Technologies, Linaro
> Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
> "Work should be fun and collaborative, the rest follows"
> --
> Stratos-dev mailing list
> Stratos-dev(a)op-lists.linaro.org
> https://op-lists.linaro.org/mailman/listinfo/stratos-dev
All
We have been using the 3pm GMT slot on Thursdays every other week for the
sync call, unfortunately this repeatedly clashes with an all hands Linaro
call, as it does this week
I propose we make it the 2.00pm GMT Thursday slot every other week, any
other suggestions ?
Mike
--
Mike Holmes | Director, Foundation Technologies, Linaro
Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
"Work should be fun and collaborative, the rest follows"
Hi,
Looking at the history of VirtIO is seems very much like virtio-mmio is
treated as the legacy interface with most of the action to date being
directed at virtio-pci which has a number of advantages including:
- already specified behaviour and driver model
- enumeration support
- support for MSI signals
The benefits of this have even led to specs for alternative
transport/devices such and IVSHMEMv2 being based around a PCI device
model.
There are detractors however, most notably the new microvm machine types
have chosen virtio-mmio's static assignment because it allows for a
faster spin up of VMs as you don't need to deal with specified settle
times in the spec.
Azzedine mentioned in a previous call that the PCI device model adds
complications based on assumptions about real HW which might not be
relevant to virtual devices. Others have mentioned the increased
complexity of the code base to handle a full PCI device.
I'm curious to what the implications are for supporting PCI in type-1
hypervisors? Is the desire to avoid handling all the details of PCI
within the small hypervisor code base and punt details to the Dom0
causing more vmexits?
As Srivatsa mentioned there have been some attempts to update the
virtio-mmio spec to support MSI IRQs which I think are the best way to
minimise unwanted context switches. So should we raise a card to help
with that effort?
Work that would be involved:
- defining the out-of-band information (MSI irqs in device tree?)
- updating the spec
- supporting MSI in the virtio-mmio front-end
Anything else?
Of course one worry would be that by adding all this additional
functionality to virtio-mmio you start to approach the complexity of
virtio-pci. I don't know if this is a real worry but I suspect people
using virtio-mmio for speed won't want any optional enhancements to slow
it down.
Thoughts?
--
Alex Bennée
Hi Stefano,
I thought I'd better commit the idea to email (and the list) so we can
work out what's feasible.
Concept:
Boot AGL Linux on two different boards/hypervisors
Detail:
We build AGL Linux with VirtIO block/network enabled in the kernel. We
then take the single image (blockdev with firmware boot or direct
kernel boot?) and demonstrate it booting on two different hardware
platforms with two different hypervisors.
System 1:
MACCHIATOBin (4xA72)
Debian Host OS + KVM
Boot with QEMU + KVM
System 2
Ultra 96 (2xA53 + 2xR5s)
Xen Hypervisor boot
DomU Debian
We could use different backends for the block device on each setup, say
LVM and qcow2?
Could we make it more engaging? How much effort would it be to get some
sort of graphics up and running?
Things to build:
- AGL Linux
- Demo Boxes
- Xen + virtio (out-of-tree)
Thoughts?
--
Alex Bennée