Add 16z069 Watchdog over MEN Chameleon BUS emulation.
Signed-off-by: Johannes Thumshirn
---
hw/watchdog/Kconfig | 5 +
hw/watchdog/meson.build | 1 +
hw/watchdog/trace-events | 6 ++
hw/watchdog/wdt_z069.c | 207 +++
4 files changed, 219
The MEN Chameleon Bus (MCB) is an on-chip bus system exposing IP Cores of an
FPGA to a outside bus system like PCIe.
Acked-by: Alistair Francis
Signed-off-by: Johannes Thumshirn
---
MAINTAINERS | 6 ++
hw/Kconfig | 1 +
hw/mcb/Kconfig | 2 +
hw/mcb/mcb.c
Add PCI based MEN Chameleon Bus carrier emulation.
Acked-by: Alistair Francis
Signed-off-by: Johannes Thumshirn
---
hw/mcb/Kconfig | 6 +
hw/mcb/mcb-pci.c| 298
hw/mcb/meson.build | 1 +
hw/mcb/trace-events | 4 +
hw/mcb/trace.h
MCB and a watchdog timer.
Changes since v2:
- Converted DPRINTF() to tracing infrastructure again (Alistair)
Changes since v2:
- Adjusted license to GPL 2 or later (Peter)
Changes since v1:
- Converted DPRINTF() to tracing infrastructure (Alistair)
- Fixed style issues (Alistair)
Johannes
Add MEN z125 UART over MEN Chameleon Bus emulation.
Acked-by: Alistair Francis
Signed-off-by: Johannes Thumshirn
---
hw/char/Kconfig | 6 +++
hw/char/meson.build | 1 +
hw/char/serial-mcb.c | 115 +++
3 files changed, 122 insertions(+)
create
mment from the previous versions about using traces instead of
macro prints
Of cause, you're right. I'm stupid, sorry.
Johannes
Add PCI based MEN Chameleon Bus carrier emulation.
Signed-off-by: Johannes Thumshirn
---
hw/mcb/Kconfig | 6 +
hw/mcb/mcb-pci.c| 297
hw/mcb/meson.build | 1 +
hw/mcb/trace-events | 3 +
hw/mcb/trace.h | 1 +
meson.build
Add MEN z125 UART over MEN Chameleon Bus emulation.
Acked-by: Alistair Francis
Signed-off-by: Johannes Thumshirn
---
hw/char/Kconfig | 6 +++
hw/char/meson.build | 1 +
hw/char/serial-mcb.c | 115 +++
3 files changed, 122 insertions(+)
create
The MEN Chameleon Bus (MCB) is an on-chip bus system exposing IP Cores of an
FPGA to a outside bus system like PCIe.
Acked-by: Alistair Francis
Signed-off-by: Johannes Thumshirn
---
MAINTAINERS | 6 ++
hw/Kconfig | 1 +
hw/mcb/Kconfig | 2 +
hw/mcb/mcb.c
Add 16z069 Watchdog over MEN Chameleon BUS emulation.
Signed-off-by: Johannes Thumshirn
---
hw/watchdog/Kconfig | 5 +
hw/watchdog/meson.build | 1 +
hw/watchdog/wdt_z069.c | 218
3 files changed, 224 insertions(+)
create mode 100644 hw
MCB and a watchdog timer.
Changes since v2:
- Adjusted license to GPL 2 or later (Peter)
Changes since v1:
- Converted DPRINTF() to tracing infrastructure (Alistair)
- Fixed style issues (Alistair)
Johannes Thumshirn (4):
Add MEN Chameleon Bus emulation
Add MEN Chameleon Bus via PCI carrier
On 06/04/2023 12:01, Peter Maydell wrote:
On Thu, 6 Apr 2023 at 10:34, Johannes Thumshirn wrote:
The MEN Chameleon Bus (MCB) is an on-chip bus system exposing IP Cores of an
FPGA to a outside bus system like PCIe.
Acked-by: Alistair Francis
Signed-off-by: Johannes Thumshirn
@@ -0,0 +1,182
Add 16z069 Watchdog over MEN Chameleon BUS emulation.
Signed-off-by: Johannes Thumshirn
---
hw/watchdog/Kconfig | 5 +
hw/watchdog/meson.build | 1 +
hw/watchdog/wdt_z069.c | 218
3 files changed, 224 insertions(+)
create mode 100644 hw
Add MEN z125 UART over MEN Chameleon Bus emulation.
Acked-by: Alistair Francis
Signed-off-by: Johannes Thumshirn
---
hw/char/Kconfig | 6 +++
hw/char/meson.build | 1 +
hw/char/serial-mcb.c | 115 +++
3 files changed, 122 insertions(+)
create
MCB and a watchdog timer.
Changes since v1:
- Converted DPRINTF() to tracing infrastructure (Alistair)
- Fixed style issues (Alistair)
Johannes Thumshirn (4):
Add MEN Chameleon Bus emulation
Add MEN Chameleon Bus via PCI carrier
serial-mcb: Add serial via MEN chameleon bus
wdt_z069: Add
Add PCI based MEN Chameleon Bus carrier emulation.
Signed-off-by: Johannes Thumshirn
---
hw/mcb/Kconfig | 6 +
hw/mcb/mcb-pci.c| 297
hw/mcb/meson.build | 1 +
hw/mcb/trace-events | 3 +
hw/mcb/trace.h | 1 +
meson.build
The MEN Chameleon Bus (MCB) is an on-chip bus system exposing IP Cores of an
FPGA to a outside bus system like PCIe.
Acked-by: Alistair Francis
Signed-off-by: Johannes Thumshirn
---
MAINTAINERS | 6 ++
hw/Kconfig | 1 +
hw/mcb/Kconfig | 2 +
hw/mcb/mcb.c
Add MEN z125 UART over MEN Chameleon Bus emulation.
Signed-off-by: Johannes Thumshirn
---
hw/char/Kconfig | 6 +++
hw/char/meson.build | 1 +
hw/char/serial-mcb.c | 115 +++
3 files changed, 122 insertions(+)
create mode 100644 hw/char/serial
Add PCI based MEN Chameleon Bus carrier emulation.
Signed-off-by: Johannes Thumshirn
---
hw/mcb/Kconfig | 6 +
hw/mcb/mcb-pci.c | 307 +
hw/mcb/meson.build | 1 +
3 files changed, 314 insertions(+)
create mode 100644 hw/mcb/mcb-pci.c
diff
The MEN Chameleon Bus (MCB) is an on-chip bus system exposing IP Cores of an
FPGA to a outside bus system like PCIe.
Signed-off-by: Johannes Thumshirn
---
MAINTAINERS | 6 ++
hw/Kconfig | 1 +
hw/mcb/Kconfig | 2 +
hw/mcb/mcb.c | 182
MCB and a watchdog timer.
Johannes Thumshirn (4):
Add MEN Chameleon Bus emulation
Add MEN Chameleon Bus via PCI carrier
serial-mcb: Add serial via MEN chameleon bus
wdt_z069: Add support for MEN 16z069 Watchdog
MAINTAINERS | 6 +
hw/Kconfig | 1 +
hw/char
Add 16z069 Watchdog over MEN Chameleon BUS emulation.
Signed-off-by: Johannes Thumshirn
---
hw/watchdog/Kconfig | 5 +
hw/watchdog/meson.build | 1 +
hw/watchdog/wdt_z069.c | 218
3 files changed, 224 insertions(+)
create mode 100644 hw
/show_bug.cgi?id=14362
Signed-off-by: Johannes Stoelp
---
v1:
- Changed ioctl request from 'unsigned' -> 'unsigned long' in kvm ioctl
wrapper.
v0:
- Changed ioctl request from 'int' -> 'unsigned' in kvm ioctl wrapper.
- L: https://lists.nongnu.org/archive/html/qemu-devel/2021-08/ms
would agree to 'unsigned long', in that case I can generate a new patch.
And in theory if all libc implementations specify the ioctl request as
'int' we could go back to 'int'.
Johannes
gt; # ignores the upper bits exactly because of possible sign confusion.
Sounds like we are saved be the Linux Kernel here :)
In my opinion we should use 'unsigned' data types here for the ioctl
request in the ioctl wrappers or would you prefer to keep the ioctl
wrapper definition as is today? What is you opinion?
Thanks and best,
Johannes
From: johannst
Ping.
https://patchew.org/QEMU/20210805193950.514357-1-johannes.sto...@gmail.com/
https://lore.kernel.org/qemu-devel/20210805193950.514357-1-johannes.sto...@gmail.com/
Thanks and best,
Johannes
From: johannst
Ping.
https://patchew.org/QEMU/20210805193950.514357-1-johannes.sto...@gmail.com/
https://lore.kernel.org/qemu-devel/20210805193950.514357-1-johannes.sto...@gmail.com/
Thanks and best,
Johannes
Hi Philippe,
On Fri, 30 Apr 2021, Philippe Mathieu-Daudé wrote:
> The first 3 patches are trivial leak fixes, the last
> one is a RFC since I have no clue about this code.
>
> Johannes, you wrote this 18 years ago, do you still
> remember? =)
I do remember writing them, but I
This might be less common in 5.2.0 but I have still had some strange
issues with keyboard.
** Changed in: qemu
Status: Expired => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906180
Still happens in 5.2.0 (Debian 1:5.2+dfsg-3~bpo10+1). Is this just due
to hardware which is too old?
** Changed in: qemu
Status: Expired => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I've been testing this with SDL interface but haven't yet encountered
this bug. So this might be specific to the GTK interface.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906180
Title:
I installed Qemu 5.0.0 from Debian Buster backports and I still get this
error.
qemu_gl_create_compile_shader: compile vertex error
0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10,
1.20, and 1.00 ES
qemu_gl_create_compile_shader: compile fragment error
0:2(10):
Public bug reported:
QEMU start command is:
qemu-system-x86_64 -enable-kvm -m 2G -cpu host -smp 2 -cdrom
./linuxmint-20-mate-64bit.iso -boot d -vga virtio -soundhw hda -display
gtk,gl=on
and QEMU crashes immediately on startup and gives these error messages:
qemu_gl_create_compile_shader:
I'm running it on local desktop.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906180
Title:
Keyboard keys get stuck
Status in QEMU:
Incomplete
Bug description:
Keyboard keys get "stuck"
I've encountered this with GTK interface. I'll test if this occurs with
SDL too.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906180
Title:
Keyboard keys get stuck
Status in QEMU:
Incomplete
Public bug reported:
Guest display resolution cannot be changed with certain virtual graphics
card (-vga) and interface (-display) combinations.
For example, resolution changing doesn't work with the following QEMU
start commands, it resets to the default resolution immediately:
QXL with SDL
Public bug reported:
When listening to music (e.g. with VLC) or watching Youtube on the
guest, there's lots of stuttering and crackling in the sound.
Tested with the following QEMU start commands:
qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom
Public bug reported:
Sometimes mouse goes completely crazy and starts jumping around the
guest desktop by itself and becomes completely unusable.
This does not happen on every boot, only sometimes. It may be caused by
some input combination but I haven't yet found any specific cause. It
happens
Public bug reported:
Keyboard keys get "stuck" quite often, on certain Linux guests at least,
and start repeating themselves until another key is pressed. This is
especially noticeable with key combinations like Ctrl+V for pasting.
When it happens, you get the pasted text and
On Thu, 2020-01-23 at 09:17 +0100, Johannes Berg wrote:
> Hi,
>
> Here's a repost of all the patches I sent back in August, with the
> in-band notifications rebased over the reset patch, so IDs have now
> changed a bit.
Ping?
The patches still apply on top of latest qemu.
I want
From: Johannes Berg
The code here is odd, for example will it print out invalid
file descriptor numbers that were never sent in the message.
Clean that up a bit so it's actually possible to implement
a device that uses polling.
Signed-off-by: Johannes Berg
---
contrib/libvhost-user/libvhost
From: Johannes Berg
Add support for VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS, but
as it's not desired by default, don't enable it unless the device
implementation opts in by returning it from its protocol features
callback.
Note that I updated vu_set_vring_err_exec(), but didn't add any
From: Johannes Berg
For good reason, vhost-user is currently built asynchronously, that
way better performance can be obtained. However, for certain use
cases such as simulation, this is problematic.
Consider an event-based simulation in which both the device and CPU
have scheduled according
collected reviewed-by's from the previous patches here.
Let me know if I should make any further edits here or in follow-up
patches.
Thanks,
johannes
From: Johannes Berg
If we use NULL, we just get the main program default mainloop
here. Using g_main_context_get_thread_default() has basically
the same effect, but it lets us start different devices in
different threads with different mainloops, which can be useful.
Reviewed-by: Stefan
From: Johannes Berg
If you try to make a device implementation that can handle multiple
connections and allow disconnections (which requires overriding the
VHOST_USER_NONE handling), then glib will warn that we remove a src
while it's still on the mainloop, and will poll() an FD that doesn't
From: Johannes Berg
This is really simple, since we know whether a response is
already requested or not, so we can just send a (successful)
response when there isn't one already.
Given that, it's not all _that_ useful but the master can at
least be sure the message was processed, and we can
ith a (hand-
written) recursive mainloop as a single thread, and it works way better.
One of these days I need to sit down and port that to be independent of
my testing framework, so I can show the code ...
johannes
lly seems to reports an FD
as readable when it's not, so I even put them into non-blocking mode :(
The second is that I can't seem to understand how to do recursive
mainloops.
To really do this *well*, it should remain a single-threaded
application, but would need a hook like
run_mainloop_until_fd_readable(vdev->call_fd)
inside the libvhost-user.c code, and that's a bit ugly ... if I even
could figure out how to implement that in glib.
johannes
u_set_vring_err_exec()
would indeed then not be necessary, but in vu_set_vring_call_exec() we
should still avoid the eventfd_write() if it's going to get -1.
So, yeah - could be a bit simpler there. I'd say being explicit here is
easier to understand and thus nicer, but your (or Michael's I guess?)
call.
johannes
From: Johannes Berg
Add support for VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS, but
as it's not desired by default, don't enable it unless the device
implementation opts in by returning it from its protocol features
callback.
Note that I updated vu_set_vring_err_exec(), but didn't add any
From: Johannes Berg
For good reason, vhost-user is currently built asynchronously, that
way better performance can be obtained. However, for certain use
cases such as simulation, this is problematic.
Consider an event-based simulation in which both the device and CPU
have scheduled according
From: Johannes Berg
This implements
* the UM protocol to access the simulation calendar,
* the underlying simulation calendar, and
* a very trivial simulated network as a vhost-user
virtio_net device.
Currently the code is a bit rough and mostly an example,
things such as the network
From: Johannes Berg
The code here is odd, for example will it print out invalid
file descriptor numbers that were never sent in the message.
Clean that up a bit so it's actually possible to implement
a device that uses polling.
Signed-off-by: Johannes Berg
---
contrib/libvhost-user/libvhost
From: Johannes Berg
If we use NULL, we just get the main program default mainloop
here. Using g_main_context_get_thread_default() has basically
the same effect, but it lets us start different devices in
different threads with different mainloops, which can be useful.
Signed-off-by: Johannes
ting/stopping ring needs to be updated, teaching it
> that ring is started after it gets a kick.
Makes sense, mostly I just need to actually *implement* that.
johannes
for simulation
work, and in that case no polling will be doable.
If you do think it's important to not make the two mutually exclusive,
how would you prefer to have this handled? With a new flag, e.g. in bit
9, indicating "use inband signalling instead of polling or eventfd"?
Thanks,
johannes
e's a way to have the device make
the connection to a listening unix domain socket, as implied by the
spec? I cannot find evidence for such a mode in any code...
johannes
No, the calls (or more specifically the REPLY_ACK to them) are really in
simulation to only acknowledge the interrupt (kick/call) signal has been
received and accounted for on the simulation calendar, the actual
processing happens when the calendar event is scheduled.
johannes
es.
But I think enough words have been expended on explaining it already, if
I may kindly ask you to read the discussions with Stefan and Michael
here:
https://lore.kernel.org/qemu-devel/20190902121233.13382-1-johan...@sipsolutions.net/
Thanks,
johannes
On Wed, 2019-09-11 at 17:36 +0200, Johannes Berg wrote:
> On Wed, 2019-09-11 at 17:31 +0200, Stefan Hajnoczi wrote:
>
> > > +``VHOST_USER_VQ_CALL``
It should also be VRING, not VQ, but I did indeed fix that in v2 already
along with the CALL<->KICK inversion.
So I guess I
message types
> > ---
> >
> > @@ -1246,6 +1265,19 @@ Slave message types
> >``VHOST_USER_PROTOCOL_F_HOST_NOTIFIER`` protocol feature has been
> >successfully negotiated.
> >
> > +``VHOST_USER_VQ_KICK``
>
> s/KICK/CALL/
Indeed. Wait, that should be VHOST_USER_SLAVE_VQ_CALL, actually. Maybe I
already did fix that in v2?
johannes
_PROTOCOL_F_IN_BAND_NOTIFICATIONS`` protocol
> > + feature has been successfully negotiated, this message may be
> > + submitted by the slave to indicate that a buffer was used from
> > + the vring instead of signalling this using the vring's kick FD or
> > + having the master relying on polling.
>
> call FD?
I confused this far too many times and thought I got it right finally,
but yes, you're right.
johannes
From: Johannes Berg
Add support for VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS, but
as it's not desired by default, don't enable it unless the device
implementation opts in by returning it from its protocol features
callback.
Note that I updated vu_set_vring_err_exec(), but didn't add any
From: Johannes Berg
For good reason, vhost-user is currently built asynchronously, that
way better performance can be obtained. However, for certain use
cases such as simulation, this is problematic.
Consider an event-based simulation in which both the device and CPU
have scheduled according
Here's a respin of both the docs and the code, hopefully addressing
most of the requests from review. Let me know if I've missed anything
or not done it in the way you thought.
Thanks,
johannes
other
errors probably should also close the FD?
johannes
On Wed, 2019-09-11 at 09:35 +0200, Stefan Hajnoczi wrote:
> On Tue, Sep 10, 2019 at 05:14:36PM +0200, Johannes Berg wrote:
> > On Tue, 2019-09-10 at 17:03 +0200, Stefan Hajnoczi wrote:
> > > > Now, this means that the CPU (that's part of the simulation) has to
> > >
On Mon, 2019-09-09 at 15:50 +0200, Johannes Berg wrote:
> > We can document how to behave in case of inconsistent protocol features,
> > yes.
>
> OK.
Coming back to this, I was just looking at it.
How/where would you like to see this done?
There isn't really any
On Tue, 2019-09-10 at 11:33 -0400, Michael S. Tsirkin wrote:
> On Tue, Sep 10, 2019 at 05:14:36PM +0200, Johannes Berg wrote:
> > Is any of you familiar with the process of getting a virtio device ID
> > assigned, and if so, do you think it'd be feasible? Without that, it
ich
is an optimization to not have to talk to the calendar all the time.
Is any of you familiar with the process of getting a virtio device ID
assigned, and if so, do you think it'd be feasible? Without that, it'd
probably be difficult to upstream the patch to support this protocol to
user-mode Linux.
Thanks,
johannes
here are quite a few papers proposing such simulation systems, I only
found the VMSimInt one publishing their code, but even that is some
hacks on top of qemu 1.6.0...
johannes
On Mon, 2019-09-09 at 11:45 -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 09, 2019 at 05:34:13PM +0200, Johannes Berg wrote:
> > On Mon, 2019-09-09 at 17:26 +0200, Johannes Berg wrote:
> > > Maybe instead we should just add a "VHOST_USER_REPLY_ERROR" bit (e.g.
> &g
On Mon, 2019-09-09 at 17:26 +0200, Johannes Berg wrote:
>
> Maybe instead we should just add a "VHOST_USER_REPLY_ERROR" bit (e.g.
> bit 4 after NEED_REPLY). Qemu in vhost_user_read_header() validates that
> it received REPLY_MASK | VERSION, so it would reject the m
num with possible
values, then I'd probably prefer an 8-byte status since that's the way
everything works now, but I don't really care much either way.
johannes
hing else.
>
> Exactly for this reason :)
:)
> > Unless you also wanted to write into the spec that F_KICK_CALL_MSGS
> > absolutely *requires* F_REPLY_ACK,
>
> yep
Sure, I'm fine with that.
> We can document how to behave in case of inconsistent protocol features,
> yes.
OK.
johannes
less as libvhost-user is
more of a sample implementation than anything else.
Unless you also wanted to write into the spec that F_KICK_CALL_MSGS
absolutely *requires* F_REPLY_ACK, and add some text that tells a device
how to behave when F_KICK_CALL_MSGS is negotiated without F_REPLY_ACK?
johannes
so I'll post new patches in a
few days or so.
johannes
than everyone having
their own local hacks for everything, like e.g. the VMSimInt paper(**).
But again, like I said, no hard feelings if you think such simulation
has no place in upstream vhost-user.
(**) I put a copy of their qemu changes on top of 1.6.0 here:
https://p.sipsolutions.net/af9a68ded948c07e.txt
johannes
Hi,
On Fri, 2019-09-06 at 10:22 -0400, Michael S. Tsirkin wrote:
> On Fri, Sep 06, 2019 at 03:13:50PM +0300, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > Signed-off-by: Johannes Berg
>
> a bit more content here about the motivation for this?
Heh, right, def
From: Johannes Berg
Signed-off-by: Johannes Berg
---
contrib/libvhost-user/libvhost-user.c | 61 +++
contrib/libvhost-user/libvhost-user.h | 3 ++
2 files changed, 56 insertions(+), 8 deletions(-)
diff --git a/contrib/libvhost-user/libvhost-user.c
b/contrib/libvhost
entation now for my simulation environment, and I guess I can keep
that private etc. but if there's interest I can submit an (optional)
implementation of this for libvhost-user too, I think.
johannes
From: Johannes Berg
This simplifies the various has_feature() checks, we already
have vu_has_feature() but it checks features, not protocol
features.
Signed-off-by: Johannes Berg
---
contrib/libvhost-user/libvhost-user.c | 20 ++--
1 file changed, 10 insertions(+), 10
From: Johannes Berg
It doesn't look like this could possibly work properly since
VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD is defined to 10, but the
dev->protocol_features has a bitmap. I suppose the peer this
was tested with also supported VHOST_USER_PROTOCOL_F_LOG_SHMFD,
in which case the test wo
From: Johannes Berg
It doesn't look like this could possibly work properly since
VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD is defined to 10, but the
dev->protocol_features has a bitmap. I suppose the peer this
was tested with also supported VHOST_USER_PROTOCOL_F_LOG_SHMFD,
in which case the test wo
From: Johannes Berg
This is really simple, since we know whether a response is
already requested or not, so we can just send a (successful)
response when there isn't one already.
Given that, it's not all _that_ useful but the master can at
least be sure the message was processed, and we can
lendar, the latter of which is necessary anyway.
Hopefully I've managed to explain what I'm trying to do here, questions or
suggestions are always welcome :-)
johannes
[1] http://www.ikr.uni-stuttgart.de/INDSimLib/
[2] https://patchwork.ozlabs.org/patch/1140033/
[3]
http://www.ikr.uni-s
From: Johannes Berg
For good reason, vhost-user is currently built asynchronously, that
way better performance can be obtained. However, for certain use
cases such as simulation, this is problematic.
Consider an event-based simulation in which both the device and CPU
have are scheduled
From: Johannes Berg
If you try to make a device implementation that can handle multiple
connections and allow disconnections (which requires overriding the
VHOST_USER_NONE handling), then glib will warn that we remove a src
while it's still on the mainloop, and will poll() an FD that doesn't
free to add a second commit to fix that too.
I looked at it briefly but couldn't unwind the paths, sorry.
johannes
From: Johannes Berg
If you try to make a device implementation that can handle multiple
connections and allow disconnections (which requires overriding the
VHOST_USER_NONE handling), then glib will warn that we remove a src
while it's still on the mainloop, and will poll() an FD that doesn't
From: Johannes Berg
If you try to make a device implementation that can handle multiple
connections and allow disconnections (which requires overriding the
VHOST_USER_NONE handling), then glib will warn that we remove a src
while it's still on the mainloop, and will poll() an FD that doesn't
Hi,
> What other problems? Sure we need the caller to unref.
Don't recall, and now I can't reproduce it, sorry.
> > > Imho, we should change the behaviour of the function to return a ref
> > > source.
> >
> > Which "the function" do you mean?
>
> The vug_source_new() function.
[...]
> Sure we
On Tue, 2019-08-27 at 14:47 +0400, Marc-André Lureau wrote:
> Hi
>
> On Tue, Aug 27, 2019 at 12:32 PM Johannes Berg
> wrote:
> > From: Johannes Berg
> >
> > If you try to make a device implementation that can handle multiple
> > connections and allow disco
From: Johannes Berg
If you try to make a device implementation that can handle multiple
connections and allow disconnections (which requires overriding the
VHOST_USER_NONE handling), then glib will warn that we remove a src
while it's still on the mainloop, and will poll() an FD that doesn't
t-user-blk and vhost-user-scsi examples in the contrib/ directory.
Awesome, thanks!
johannes
I guess there might be better documentation on the ioctl interfaces?
Do you know if there's a sample client/server somewhere?
I guess we should implement the server in UML like it is in QEMU (unless
we can figure out how to virtualize the time with HPET or something in
QEMU) and then have our client and kernel driver for it...
Thanks a lot!
johannes
all out to some RPC that contains the real model.
Now that I thought about it further, I guess my question boils down to
"did anyone ever think about doing RPC for Virt-IO instead of putting
the entire device model into the hypervisor/emulator/...".
johannes
)?
Thanks,
johannes
[1] Actually, I've considered using qemu, but it doesn't have
virtualized time and doesn't seem to support TSC virtualization. I guess
I could remove TSC from the guest CPU and add a virtualized HPET, but
I've yet to convince myself this works - on UML I made virtual time
Add MEN z125 UART over MEN Chameleon Bus emulation.
Signed-off-by: Johannes Thumshirn
---
hw/char/Makefile.objs | 1 +
hw/char/serial-mcb.c | 100 ++
2 files changed, 101 insertions(+)
create mode 100644 hw/char/serial-mcb.c
diff --git a/hw
1 - 100 of 402 matches
Mail list logo
