Re: Any interest in a QEMU emulation BoF at KVM Forum?

[Daniel P . Berrangé]

On Tue, Sep 13, 2022 at 09:16:07AM +0200, Cédric Le Goater wrote:
> On 9/13/22 09:12, Alex Bennée wrote:
> > The BoF session will be in Lifey A (the big hall) this afternoon. I thought 
> > being able to sit around tables while we discuss things would make things a 
> > bit easier. We can share note taking on the etherpad:
> > 
> > https://etherpad.opendev.org/p/qemu-emulation-bof%40kvmforum2022 
> > 
> > 
> > I'll run a HO at: https://meet.google.com/rac-axef-xvv 
> > 
> 
> Thanks for that. I will try to join. What time approximately ?

The Tuesday BoF slot is 17:40-18:10

  https://events.linuxfoundation.org/kvm-forum/program/schedule/

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: Any interest in a QEMU emulation BoF at KVM Forum?

[Cédric Le Goater]

On 9/13/22 09:12, Alex Bennée wrote:

The BoF session will be in Lifey A (the big hall) this afternoon. I thought 
being able to sit around tables while we discuss things would make things a bit 
easier. We can share note taking on the etherpad:

https://etherpad.opendev.org/p/qemu-emulation-bof%40kvmforum2022 


I'll run a HO at: https://meet.google.com/rac-axef-xvv 



Thanks for that. I will try to join. What time approximately ?

C.




On Wed, 31 Aug 2022 at 16:19, Alex Bennée mailto:alex.ben...@linaro.org>> wrote:

Hi,

Given our slowly growing range of TCG emulations and the evident
interest in keeping up with modern processor architectures is it worth
having an emulation focused BoF at the up-coming KVM Forum?

Some potential topics for discussion I could think of might include:

  * Progress towards heterogeneous vCPU emulation

  We've been making slow progress in removing assumptions from the
  various front-ends about their global nature and adding accel:TCG
  abstractions and support for the translator loop. We can already have
  CPUs from the same architecture family in a model. What else do we need
  to do so we can have those funky ARM+RiscV+Tricore heterogeneous
  models? Is it library or something else?

  * External Device Models

  I know this is a contentious topic given the potential for GPL
  end-runs. However there are also good arguments for enabling the
  testing of open source designs without having forcing the
  implementation of a separate C model to test software. For example if
  we hypothetically modelled a Pi Pico would it make sense to model the
  PIO in C if we could just compile the Verilog for it into a SystemC
  model? Would a plethora of closed device models be the inevitable
  consequence of such an approach? Would it matter if we just
  concentrated on supporting useful open source solutions?

  * Dynamic Machine Models

  While we try and avoid modelling bespoke virtual HW in QEMU
  (virt/goldfish not withstanding ;-) there is obviously a desire in the
  EDA space to allow such experimentation. Is this something we can
  provide so aspiring HW engineers can experiment with system
  architectures without having to form QEMU and learn QOM. There have
  been suggestions about consuming device trees or maybe translating to
  QMP calls and adding support for wiring devices together. Given the
  number of forks that exist is this something that could be better
  supported upstream without degenerating into messy hacks?

  * A sense of time

  Currently we have the fairly limited support for -icount in QEMU. At
  the same time we have no desire to start expanding frontends with
  the details cost models required for a more realistic sense of time to
  be presented. One suggestion is to expand the TCG plugin interface to
  allow for the plugin to control time allowing as much or little logic
  to be pushed there as we like and freeing up frontends from ever having
  to consider it.

Are any of these topics of interest? Are there any other emulation
topics people would like to discuss?

-- 
Alex Bennée




--
Alex Bennée
KVM/QEMU Hacker for Linaro

Re: Any interest in a QEMU emulation BoF at KVM Forum?

[Alex Bennée]

The BoF session will be in Lifey A (the big hall) this afternoon. I thought
being able to sit around tables while we discuss things would make things a
bit easier. We can share note taking on the etherpad:

  https://etherpad.opendev.org/p/qemu-emulation-bof%40kvmforum2022

I'll run a HO at: https://meet.google.com/rac-axef-xvv

On Wed, 31 Aug 2022 at 16:19, Alex Bennée  wrote:

> Hi,
>
> Given our slowly growing range of TCG emulations and the evident
> interest in keeping up with modern processor architectures is it worth
> having an emulation focused BoF at the up-coming KVM Forum?
>
> Some potential topics for discussion I could think of might include:
>
>  * Progress towards heterogeneous vCPU emulation
>
>  We've been making slow progress in removing assumptions from the
>  various front-ends about their global nature and adding accel:TCG
>  abstractions and support for the translator loop. We can already have
>  CPUs from the same architecture family in a model. What else do we need
>  to do so we can have those funky ARM+RiscV+Tricore heterogeneous
>  models? Is it library or something else?
>
>  * External Device Models
>
>  I know this is a contentious topic given the potential for GPL
>  end-runs. However there are also good arguments for enabling the
>  testing of open source designs without having forcing the
>  implementation of a separate C model to test software. For example if
>  we hypothetically modelled a Pi Pico would it make sense to model the
>  PIO in C if we could just compile the Verilog for it into a SystemC
>  model? Would a plethora of closed device models be the inevitable
>  consequence of such an approach? Would it matter if we just
>  concentrated on supporting useful open source solutions?
>
>  * Dynamic Machine Models
>
>  While we try and avoid modelling bespoke virtual HW in QEMU
>  (virt/goldfish not withstanding ;-) there is obviously a desire in the
>  EDA space to allow such experimentation. Is this something we can
>  provide so aspiring HW engineers can experiment with system
>  architectures without having to form QEMU and learn QOM. There have
>  been suggestions about consuming device trees or maybe translating to
>  QMP calls and adding support for wiring devices together. Given the
>  number of forks that exist is this something that could be better
>  supported upstream without degenerating into messy hacks?
>
>  * A sense of time
>
>  Currently we have the fairly limited support for -icount in QEMU. At
>  the same time we have no desire to start expanding frontends with
>  the details cost models required for a more realistic sense of time to
>  be presented. One suggestion is to expand the TCG plugin interface to
>  allow for the plugin to control time allowing as much or little logic
>  to be pushed there as we like and freeing up frontends from ever having
>  to consider it.
>
> Are any of these topics of interest? Are there any other emulation
> topics people would like to discuss?
>
> --
> Alex Bennée
>


-- 
Alex Bennée
KVM/QEMU Hacker for Linaro

Re: Any interest in a QEMU emulation BoF at KVM Forum?

[Alessandro Di Federico via]

I'm very interested too. Thanks for organizing this, Alex!

In particular we're interested in the infrastructure work to enable
having a single build of QEMU using several different TCG frontends,
which is probably preliminary to heterogeneous vCPU emulation.

In fact, I was going to send an RFC about this to qemu-devel, but KVM
Forum + this BoF seemed like a good opportunity to discuss this. I
might share it later, if you're intersted.

Will the BoF pop up in the program or will it be something informal?
According to the schedule, there are BoFs Mon 17.40 and Tue 17.40.

Catch you in Dublin and thanks again for setting this up.

-- 
Alessandro Di Federico
rev.ng Labs

Re: 回复：Any interest in a QEMU emulation BoF at KVM Forum?

[Alex Bennée]

"刘志伟"  writes:

> These topics are interesting.  I have two questions.
>
> 1. Can we join it on online?  If so, could you share the meeting link before 
> the meeting.
>
> 2. If it is only offline, could you share the meeting content to the
> public?

I've created an etherpad for the day (which ever we end up doing):

  https://etherpad.opendev.org/p/qemu-emulation-bof%40kvmforum2022

-- 
Alex Bennée

Re: 回复：Any interest in a QEMU emulation BoF at KVM Forum?

[Alex Bennée]

"刘志伟"  writes:

> These topics are interesting.  I have two questions.
>
> 1. Can we join it on online?  If so, could you share the meeting link
> before the meeting.

I will try to find out.

>
> 2. If it is only offline, could you share the meeting content to the
> public?

I'll certainly try and write up some minutes for the list.

>
> Thanks,
> Zhiwei 
>
>  --
>  发件人：Alex Bennée 
>  发送时间：2022年9月1日(星期四) 01:08
>  收件人：qemu-devel@nongnu.org 
>  抄　送：Mark Burton ; Edgar E. Iglesias 
> ; Richard
>  Henderson ; Paolo Bonzini 
> ; Peter Maydell
>  ; Song Gao ; Xiaojuan Yang 
> ;
>  "Cédric Le Goater" ; Palmer Dabbelt ; 
> Alistair Francis
>  ; Bin Meng ; David Gibson 
> ;
>  Markus Armbruster ; Michael Roth ; 
> Luc Michel ;
>  Damien Hedde ; Alessandro Di Federico 
> 
>  主　题：Re: Any interest in a QEMU emulation BoF at KVM Forum?
>
>  Alex Bennée  writes:
>
>  qemu-devel keeps bouncing the message so replying with a cut down CC list.
>
>  > Hi,
>  >
>  > Given our slowly growing range of TCG emulations and the evident
>  > interest in keeping up with modern processor architectures is it worth
>  > having an emulation focused BoF at the up-coming KVM Forum?
>  >
>  > Some potential topics for discussion I could think of might include:
>  >
>  >  * Progress towards heterogeneous vCPU emulation
>  >
>  >  We've been making slow progress in removing assumptions from the
>  >  various front-ends about their global nature and adding accel:TCG
>  >  abstractions and support for the translator loop. We can already have
>  >  CPUs from the same architecture family in a model. What else do we need
>  >  to do so we can have those funky ARM+RiscV+Tricore heterogeneous
>  >  models? Is it library or something else?
>  >
>  >  * External Device Models
>  >
>  >  I know this is a contentious topic given the potential for GPL
>  >  end-runs. However there are also good arguments for enabling the
>  >  testing of open source designs without having forcing the
>  >  implementation of a separate C model to test software. For example if
>  >  we hypothetically modelled a Pi Pico would it make sense to model the
>  >  PIO in C if we could just compile the Verilog for it into a SystemC
>  >  model? Would a plethora of closed device models be the inevitable
>  >  consequence of such an approach? Would it matter if we just
>  >  concentrated on supporting useful open source solutions?
>  >
>  >  * Dynamic Machine Models
>  >
>  >  While we try and avoid modelling bespoke virtual HW in QEMU
>  >  (virt/goldfish not withstanding ;-) there is obviously a desire in the
>  >  EDA space to allow such experimentation. Is this something we can
>  >  provide so aspiring HW engineers can experiment with system
>  >  architectures without having to form QEMU and learn QOM. There have
>  >  been suggestions about consuming device trees or maybe translating to
>  >  QMP calls and adding support for wiring devices together. Given the
>  >  number of forks that exist is this something that could be better
>  >  supported upstream without degenerating into messy hacks?
>  >
>  >  * A sense of time
>  >
>  >  Currently we have the fairly limited support for -icount in QEMU. At
>  >  the same time we have no desire to start expanding frontends with
>  >  the details cost models required for a more realistic sense of time to
>  >  be presented. One suggestion is to expand the TCG plugin interface to
>  >  allow for the plugin to control time allowing as much or little logic
>  >  to be pushed there as we like and freeing up frontends from ever having
>  >  to consider it.
>  >
>  > Are any of these topics of interest? Are there any other emulation
>  > topics people would like to discuss?
>
>  -- 
>  Alex Bennée


-- 
Alex Bennée

回复：Any interest in a QEMU emulation BoF at KVM Forum?

[刘志伟]

These topics are interesting. I have two questions.
1. Can we join it on online? If so, could you share the meeting link before the 
meeting.
2. If it is only offline, could you share the meeting content to the public?
Thanks,
Zhiwei 
--
发件人：Alex Bennée 
发送时间：2022年9月1日(星期四) 01:08
收件人：qemu-devel@nongnu.org 
抄　送：Mark Burton ; Edgar E. Iglesias 
; Richard Henderson ; 
Paolo Bonzini ; Peter Maydell ; 
Song Gao ; Xiaojuan Yang ; 
"Cédric Le Goater" ; Palmer Dabbelt ; 
Alistair Francis ; Bin Meng ; 
David Gibson ; Markus Armbruster 
; Michael Roth ; Luc Michel 
; Damien Hedde ; Alessandro Di 
Federico 
主　题：Re: Any interest in a QEMU emulation BoF at KVM Forum?
Alex Bennée  writes:
qemu-devel keeps bouncing the message so replying with a cut down CC list.
> Hi,
>
> Given our slowly growing range of TCG emulations and the evident
> interest in keeping up with modern processor architectures is it worth
> having an emulation focused BoF at the up-coming KVM Forum?
>
> Some potential topics for discussion I could think of might include:
>
> * Progress towards heterogeneous vCPU emulation
>
> We've been making slow progress in removing assumptions from the
> various front-ends about their global nature and adding accel:TCG
> abstractions and support for the translator loop. We can already have
> CPUs from the same architecture family in a model. What else do we need
> to do so we can have those funky ARM+RiscV+Tricore heterogeneous
> models? Is it library or something else?
>
> * External Device Models
>
> I know this is a contentious topic given the potential for GPL
> end-runs. However there are also good arguments for enabling the
> testing of open source designs without having forcing the
> implementation of a separate C model to test software. For example if
> we hypothetically modelled a Pi Pico would it make sense to model the
> PIO in C if we could just compile the Verilog for it into a SystemC
> model? Would a plethora of closed device models be the inevitable
> consequence of such an approach? Would it matter if we just
> concentrated on supporting useful open source solutions?
>
> * Dynamic Machine Models
>
> While we try and avoid modelling bespoke virtual HW in QEMU
> (virt/goldfish not withstanding ;-) there is obviously a desire in the
> EDA space to allow such experimentation. Is this something we can
> provide so aspiring HW engineers can experiment with system
> architectures without having to form QEMU and learn QOM. There have
> been suggestions about consuming device trees or maybe translating to
> QMP calls and adding support for wiring devices together. Given the
> number of forks that exist is this something that could be better
> supported upstream without degenerating into messy hacks?
>
> * A sense of time
>
> Currently we have the fairly limited support for -icount in QEMU. At
> the same time we have no desire to start expanding frontends with
> the details cost models required for a more realistic sense of time to
> be presented. One suggestion is to expand the TCG plugin interface to
> allow for the plugin to control time allowing as much or little logic
> to be pushed there as we like and freeing up frontends from ever having
> to consider it.
>
> Are any of these topics of interest? Are there any other emulation
> topics people would like to discuss?
-- 
Alex Bennée

Re: Any interest in a QEMU emulation BoF at KVM Forum?

[Alex Bennée]

Alex Bennée  writes:

qemu-devel keeps bouncing the message so replying with a cut down CC list.

> Hi,
>
> Given our slowly growing range of TCG emulations and the evident
> interest in keeping up with modern processor architectures is it worth
> having an emulation focused BoF at the up-coming KVM Forum?
>
> Some potential topics for discussion I could think of might include:
>
>  * Progress towards heterogeneous vCPU emulation
>
>  We've been making slow progress in removing assumptions from the
>  various front-ends about their global nature and adding accel:TCG
>  abstractions and support for the translator loop. We can already have
>  CPUs from the same architecture family in a model. What else do we need
>  to do so we can have those funky ARM+RiscV+Tricore heterogeneous
>  models? Is it library or something else?
>
>  * External Device Models
>
>  I know this is a contentious topic given the potential for GPL
>  end-runs. However there are also good arguments for enabling the
>  testing of open source designs without having forcing the
>  implementation of a separate C model to test software. For example if
>  we hypothetically modelled a Pi Pico would it make sense to model the
>  PIO in C if we could just compile the Verilog for it into a SystemC
>  model? Would a plethora of closed device models be the inevitable
>  consequence of such an approach? Would it matter if we just
>  concentrated on supporting useful open source solutions?
>
>  * Dynamic Machine Models
>
>  While we try and avoid modelling bespoke virtual HW in QEMU
>  (virt/goldfish not withstanding ;-) there is obviously a desire in the
>  EDA space to allow such experimentation. Is this something we can
>  provide so aspiring HW engineers can experiment with system
>  architectures without having to form QEMU and learn QOM. There have
>  been suggestions about consuming device trees or maybe translating to
>  QMP calls and adding support for wiring devices together. Given the
>  number of forks that exist is this something that could be better
>  supported upstream without degenerating into messy hacks?
>
>  * A sense of time
>
>  Currently we have the fairly limited support for -icount in QEMU. At
>  the same time we have no desire to start expanding frontends with
>  the details cost models required for a more realistic sense of time to
>  be presented. One suggestion is to expand the TCG plugin interface to
>  allow for the plugin to control time allowing as much or little logic
>  to be pushed there as we like and freeing up frontends from ever having
>  to consider it.
>
> Are any of these topics of interest? Are there any other emulation
> topics people would like to discuss?


-- 
Alex Bennée

Re: Any interest in a QEMU emulation BoF at KVM Forum?

[Edgar E. Iglesias]

On Wed, Aug 31, 2022 at 03:35:19PM +0100, Alex Bennée wrote:
> Hi,
> 
> Given our slowly growing range of TCG emulations and the evident
> interest in keeping up with modern processor architectures is it worth
> having an emulation focused BoF at the up-coming KVM Forum?


Hi Alex,

Yes, I'd be interested in all topics you mention.

Best regards,
Edgar



> 
> Some potential topics for discussion I could think of might include:
> 
>  * Progress towards heterogeneous vCPU emulation
> 
>  We've been making slow progress in removing assumptions from the
>  various front-ends about their global nature and adding accel:TCG
>  abstractions and support for the translator loop. We can already have
>  CPUs from the same architecture family in a model. What else do we need
>  to do so we can have those funky ARM+RiscV+Tricore heterogeneous
>  models? Is it library or something else?
> 
>  * External Device Models
> 
>  I know this is a contentious topic given the potential for GPL
>  end-runs. However there are also good arguments for enabling the
>  testing of open source designs without having forcing the
>  implementation of a separate C model to test software. For example if
>  we hypothetically modelled a Pi Pico would it make sense to model the
>  PIO in C if we could just compile the Verilog for it into a SystemC
>  model? Would a plethora of closed device models be the inevitable
>  consequence of such an approach? Would it matter if we just
>  concentrated on supporting useful open source solutions?
> 
>  * Dynamic Machine Models
> 
>  While we try and avoid modelling bespoke virtual HW in QEMU
>  (virt/goldfish not withstanding ;-) there is obviously a desire in the
>  EDA space to allow such experimentation. Is this something we can
>  provide so aspiring HW engineers can experiment with system
>  architectures without having to form QEMU and learn QOM. There have
>  been suggestions about consuming device trees or maybe translating to
>  QMP calls and adding support for wiring devices together. Given the
>  number of forks that exist is this something that could be better
>  supported upstream without degenerating into messy hacks?
> 
>  * A sense of time
> 
>  Currently we have the fairly limited support for -icount in QEMU. At
>  the same time we have no desire to start expanding frontends with
>  the details cost models required for a more realistic sense of time to
>  be presented. One suggestion is to expand the TCG plugin interface to
>  allow for the plugin to control time allowing as much or little logic
>  to be pushed there as we like and freeing up frontends from ever having
>  to consider it.
> 
> Are any of these topics of interest? Are there any other emulation
> topics people would like to discuss?
> 
> -- 
> Alex Bennée

Re: Any interest in a QEMU emulation BoF at KVM Forum?

[Mark Burton]

I am VERY interested in these topics from a Qualcomm perspective. I’ll be there 
from Tuesday morning,  I think a “BoF” would be very helpful …
Cheers
Mark.



On 31/08/2022, 17:20, "Alex Bennée"  wrote:

WARNING: This email originated from outside of Qualcomm. Please be wary of any 
links or attachments, and do not enable macros.

Hi,

Given our slowly growing range of TCG emulations and the evident
interest in keeping up with modern processor architectures is it worth
having an emulation focused BoF at the up-coming KVM Forum?

Some potential topics for discussion I could think of might include:

 * Progress towards heterogeneous vCPU emulation

 We've been making slow progress in removing assumptions from the
 various front-ends about their global nature and adding accel:TCG
 abstractions and support for the translator loop. We can already have
 CPUs from the same architecture family in a model. What else do we need
 to do so we can have those funky ARM+RiscV+Tricore heterogeneous
 models? Is it library or something else?

 * External Device Models

 I know this is a contentious topic given the potential for GPL
 end-runs. However there are also good arguments for enabling the
 testing of open source designs without having forcing the
 implementation of a separate C model to test software. For example if
 we hypothetically modelled a Pi Pico would it make sense to model the
 PIO in C if we could just compile the Verilog for it into a SystemC
 model? Would a plethora of closed device models be the inevitable
 consequence of such an approach? Would it matter if we just
 concentrated on supporting useful open source solutions?

 * Dynamic Machine Models

 While we try and avoid modelling bespoke virtual HW in QEMU
 (virt/goldfish not withstanding ;-) there is obviously a desire in the
 EDA space to allow such experimentation. Is this something we can
 provide so aspiring HW engineers can experiment with system
 architectures without having to form QEMU and learn QOM. There have
 been suggestions about consuming device trees or maybe translating to
 QMP calls and adding support for wiring devices together. Given the
 number of forks that exist is this something that could be better
 supported upstream without degenerating into messy hacks?

 * A sense of time

 Currently we have the fairly limited support for -icount in QEMU. At
 the same time we have no desire to start expanding frontends with
 the details cost models required for a more realistic sense of time to
 be presented. One suggestion is to expand the TCG plugin interface to
 allow for the plugin to control time allowing as much or little logic
 to be pushed there as we like and freeing up frontends from ever having
 to consider it.

Are any of these topics of interest? Are there any other emulation
topics people would like to discuss?

--
Alex Bennée