On Wed, 2022-10-12 at 14:11 -0500, Bjorn Helgaas wrote:
> The linux-um@lists.infradead.org mailing list is listed in MAINTAINERS
> and is quite active [1]. Once in a while a commit links to the
> infradead pipermail archive [2] (the link in that commit appears
> broken).
>
> I propose that we add
On Sun, 2022-10-16 at 23:10 +0800, Dawei Li wrote:
> find_task_by_pid_ns() is safe if and only if it's under protection
> from rcu read lock, implements the protection.
>
> base-commit: 193cb8372424184dde28088a4230a5fed0afb0ad
>
> Signed-off-by: Dawei Li
> ---
> arch/um/drivers/mconsole_kern.c
From: Johannes Berg
Looks like this is needed now, otherwise we get RCU
splats from lockdep. But I don't know anything about
this code ...
Signed-off-by: Johannes Berg
---
arch/um/kernel/tlb.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/um/kernel/tlb.c b/arch/um/kernel/
On Mon, 2022-10-17 at 15:50 +0100, Matthew Wilcox wrote:
> On Mon, Oct 17, 2022 at 11:06:30AM +0200, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > Looks like this is needed now, otherwise we get RCU
> > splats from lockdep. But I don't know anything abo
From: Johannes Berg
Due to changes in the iteration, there are now lockdep
checks indicating that we're missing locking here. Fix
that.
Signed-off-by: Johannes Berg
---
arch/um/kernel/tlb.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/um/kernel/tlb.c b/arch/um/kernel/
From: Johannes Berg
Due to changes in the iteration, there are now lockdep
checks indicating that we're missing locking here. Add
the missing locking where it's needed.
Signed-off-by: Johannes Berg
---
v2: use mmap_read_lock()
v3: umm, yeah I'm an idiot, tested without rebuildi
On Tue, 2022-11-22 at 08:55 -0500, Alex Deucher wrote:
> >
> >+ /kisskb/src/arch/um/include/asm/processor-generic.h: error: called
> > object is not a function or function pointer: => 94:18
> >+ /kisskb/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:
> > error: control reaches
On Thu, 2022-12-01 at 11:22 +0200, Leon Romanovsky wrote:
>
> > +++ b/drivers/infiniband/hw/qib/Kconfig
> > @@ -3,6 +3,7 @@ config INFINIBAND_QIB
> > tristate "Intel PCIe HCA support"
> > depends on 64BIT && INFINIBAND_RDMAVT
> > depends on PCI
> > + depends on !UML
>
> I would advo
d um_pci_irq_vq_cb(struct virtqueue *vq)
> }
> }
>
> +/* Copied from arch/x86/kernel/devicetree.c */
> +struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
Hah. I was going to ask how that works without any ifdef or anything,
but then I found the __weak version :-)
Acked-by
On Tue, 2023-01-31 at 08:22 +0100, Richard Weinberger wrote:
>
> Adding function (and function graph) tracing to UML is possible but a bit of
> work.
> You need to find a way to implement all of ftraces mcount hooks for UML.
>
It feels like it shouldn't be that hard, but I coincidentally looked
From: Johannes Berg
Make some cleanups, add and fix some comments and document
here that we shouldn't export (libc) symbols for "_user.c"
code, rather such should work like hostfs does now.
Signed-off-by: Johannes Berg
---
arch/um/os-Linux/user_syms.c | 31 ---
From: Johannes Berg
By not doing the user code cflags mangling we can simply
break the build for any user code sneaking into modules.
Signed-off-by: Johannes Berg
---
arch/um/scripts/Makefile.rules | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/um/scripts
From: Johannes Berg
Instead of exporting the set of functions provided by
glibc that are needed for hostfs_user.c, just build that
into the kernel image whenever hostfs is built, and then
export _those_ functions cleanly, to be independent of
the libc implementation.
Signed-off-by: Johannes
From: Johannes Berg
Since printf() cannot be used in kernel threads (it
uses too much stack space) don't export it for modules
either.
This should leave us exporting only things that are
absolutely critical (such as memset and friends) and
things that are injected by the compiler (stack
From: Johannes Berg
If the exported glibc functions don't exist, we get link
failures. Avoid that by adding __weak so they're allowed
to not exist.
Reported-by: Randy Dunlap
Signed-off-by: Johannes Berg
---
arch/um/os-Linux/user_syms.c | 2 +-
1 file changed, 1 insertion(+),
On Fri, 2023-01-27 at 15:30 +0100, Vincent Whitchurch wrote:
> This driver registers PCI busses, but the underlying virtio protocol
> could just as easily be used to provide a platform bus instead. If the
> virtio device node in the devicetree indicates that it's compatible with
> simple-bus, regi
On Wed, 2023-02-15 at 09:07 +0100, Geert Uytterhoeven wrote:
> Hi Srinivasarao,
>
> On Wed, Feb 15, 2023 at 6:36 AM Srinivasarao Pathipati
> wrote:
> > On 2/15/2023 3:27 AM, Richard Weinberger wrote:
> > > - Ursprüngliche Mail -
> > > > Von: "Srinivasarao Pathipati"
> > > > static void s
On Tue, 2023-02-14 at 22:57 +0100, Richard Weinberger wrote:
> - Ursprüngliche Mail -
> > Von: "Srinivasarao Pathipati"
> > static void sig_handler_common(int sig, struct siginfo *si, mcontext_t *mc)
> > {
> > - struct uml_pt_regs r;
> > + struct uml_pt_regs *r;
> > int save_errno
On Tue, 2023-02-14 at 13:12 +0100, Vincent Whitchurch wrote:
>
> Yes, Greg was initially totally opposed to the idea of putting platform
> devices under PCI devices, but in his latest email he seemed to
> allow it in some cases. It's still unclear if he'd be OK with a
> "virtual PCI-to-platform b
>Hm, in the !CONFIG_GENERIC_SMP_IDLE_THREAD case, idle_thread_get() will
>have returned NULL. Won't these then crash?
>
>Admittedly that seems to be *only* for UM, as all other architectures
>with SMP seem to set CONFIG_GENERIC_SMP_IDLE_THREAD.
UM doesn't even have SMP, so maybe CONFIG_GENERIC
es "select
ISA" (only in some other architectures), so is there much point in this?
I'm not even sure why this exists at all.
But anyway, adding a dependency to a always-false symbol doesn't make it
less always-false :-)
Acked-by: Johannes Berg # for ARCH=um
Certain
Hi,
Nice. I think you can squash this into a single patch eventually. Couple
of comments below:
On Fri, 2023-04-14 at 00:30 +0200, Marko Petrović wrote:
> Signed-off-by: Marko Petrović
> ---
> ...to_v2.rst => user_mode_linux_howto_v3.rst} | 20 +--
> 1 file changed, 9 insertions
On Fri, 2023-04-14 at 04:33 +0200, Marko Petrović wrote:
> Fix GID assignment error in uml_chown() and add support for correct
> behavior when parent directory has SETGID bit.
That was the change for 'v2' I guess, but you should document here what
the new code does and why, probably a good chunk
From: Johannes Berg
There's a lot of code here that hard-codes that the
data is a single page, and right now that seems to
be sufficient, but to make it easier to change this
in the future, add a new STUB_DATA_PAGES constant
and use it throughout the code.
Signed-off-by: Johannes Berg
---
On Sun, 2023-04-09 at 18:13 -0700, Randy Dunlap wrote:
> Current build of pata_cs5536 for i386 UML fails with:
>
> ERROR: modpost: "__tracepoint_write_msr" [drivers/ata/pata_cs5536.ko]
> undefined!
> ERROR: modpost: "do_trace_write_msr" [drivers/ata/pata_cs5536.ko] undefined!
> ERROR: modpost: "_
On Fri, 2023-04-14 at 19:19 +0200, Marko Petrović wrote:
> > > +++ b/fs/hostfs/hostfs.h
> > > @@ -37,6 +37,7 @@
> > > * is on, and remove the appropriate bits from attr->ia_mode (attr is a
> > > * "struct iattr *"). -BlaisorBlade
> > > */
> > > +extern int use_xattr;
> >
> >
> > That seems
Hi,
On Sun, 2023-04-16 at 19:24 +0200, Marko Petrović wrote:
>
> I have written the third version of the patch. Thank you for all of your
> recommendations.
>
> While writing the third patch version, I noticed that there was a
> serious limitation of the code in second patch, namely the whole
>
From: Johannes Berg
Since we no longer (want to) export any libc symbols the
_user portions of any drivers need to be built into image
rather than the module. I missed this for the watchdog.
Fix the watchdog accordingly.
Reported-by: kernel test robot
Signed-off-by: Johannes Berg
---
arch/um
On Tue, 2023-04-25 at 18:35 +0200, Marko Petrović wrote:
> > It seems that _maybe_, similar to the 'hostfs' kernel argument, there
> > should be a way to contain the set of options?
> >
> > What do I mean by that? I mean that today, the inside of the virtual
> > machine (for lack of a better word)
> - strlcpy(ifr.ifr_name, pri->dev_name,
> sizeof(ifr.ifr_name));
> + strscpy(ifr.ifr_name, pri->dev_name,
> sizeof(ifr.ifr_name));
>
> > arch/um/os-Linux/drivers/tuntap_user.c: In function 'tuntap_open':
> > > > arch/um/os-Linux/drivers/tuntap_user.c:149:17: error: i
On Tue, 2023-06-06 at 21:23 -0700, Eric Biggers wrote:
>
> > > > Reported-by: kernel test robot
> > > > Closes:
> > > > https://lore.kernel.org/oe-kbuild-all/202305311135.zgmt1gyr-...@intel.com/
> > >
> > > Are you sure Reported-by and Closes make sense?
> > > AFAIK the report was only on your f
On Wed, 2023-06-07 at 17:10 +0800, Philip Li wrote:
> > > So it seems we should ask the robot maintainers to just stop suggesting
> > > those tags?
> >
> > Agreed.
>
> Thanks all for the feedback. We will carefully consider how to present the
> suggestion clearly.
>
> For now, because the bot co
On Wed, 2023-06-07 at 17:39 +0800, Philip Li wrote:
>
> Is that ok we just take this phrase as a quick improvement for first step,
> which
> is
>
> "If you fix the issue in a separate patch/commit (i.e. not just a new
> version of the same patch/commit), kindly add following tags:"
>
> This cou
On Thu, 2023-06-22 at 13:22 -0600, Rob Herring wrote:
> Hi all,
>
> I'm interested in getting UML working on Arm. Is anyone aware of any
> efforts to do this already?
Not me ... But yeah, agree that it seems likely to require some
refactoring, even if _some_ degree of attempts were made to keep
On Fri, 2023-06-23 at 16:34 -0600, Rob Herring wrote:
>
> >
> > Either way, the old patchset will give you a good idea about how it all
> > works, the changes are mostly in the details. I am happy to push out a
> > new version sooner rather than later if it might help with any efforts
> > on your
On Sat, 2023-06-24 at 22:05 +0200, Benjamin Berg wrote:
> On Sat, 2023-06-24 at 15:15 +0200, Johannes Berg wrote:
> > On Fri, 2023-06-23 at 16:34 -0600, Rob Herring wrote:
> > >
> > > >
> > > > Either way, the old patchset will give you a good idea about
On Fri, 2023-09-15 at 11:32 +0200, Ingo Molnar wrote:
>
> > ld: mm/kasan/shadow.o: in function `memset':
> > shadow.c:(.text+0x40): multiple definition of `memset';
> > arch/x86/lib/memset_64.o:(.noinstr.text+0x0): first defined here
> > ld: mm/kasan/shadow.o: in function `memmove':
> > shado
Hi,
Haven't chimed in here before, but thanks for looking at this! I
actually really wanted at least the things you get for debug from this
in the past, so much appreciated.
I think I actually tried a simpler approach and it kind of even worked,
but my userspace likely has very little FPU usage.
On Fri, 2023-09-22 at 07:52 +0100, anton.iva...@cambridgegreys.com
wrote:
>
> +++ b/arch/um/include/asm/processor-generic.h
> @@ -44,6 +44,9 @@ struct thread_struct {
> } cb;
> } u;
> } request;
> +#if defined(CONFIG_PREEMPT) || defined(CONFIG_PREEMPT_VOLU
On Fri, 2023-09-22 at 08:38 +0100, Anton Ivanov wrote:
> >
> > I had enabled CONFIG_DEBUG_ATOMIC_SLEEP because that's actually
> > something I'd really like to have in our testing.
> >
> > But with that issue I don't even know how we get there really. It
> > doesn't even happen every time we fork
On Fri, 2023-09-22 at 09:01 +0100, Anton Ivanov wrote:
>
> My favorite test which I run on all changes is:
>
> find /usr -type f -exec cat {} > /dev/null \;
>
> On Debian this forks /bin/cat for each file and does IO on it. That test
> passes here every time :(
Oh, apart from the splat, it all
>
> Yes, but when does the fork actually happen?
>
Looking further at this, now I'm confused as to why it doesn't happen
_all_ the time.
I think this has pretty much always been wrong, just now we actually
notice it?
Basically, when we create a new thread (really just mm I think), we say
the f
On Fri, 2023-09-22 at 10:41 +0200, Johannes Berg wrote:
> >
> > Yes, but when does the fork actually happen?
> >
>
> Looking further at this, now I'm confused as to why it doesn't happen
> _all_ the time.
>
> I think this has pretty much always b
On Fri, 2023-09-22 at 10:43 +0200, Johannes Berg wrote:
> >
> > I think this has pretty much always been wrong, just now we actually
> > notice it?
> >
> > Basically, when we create a new thread (really just mm I think), we say
> > the first thing that has t
On Fri, 2023-09-22 at 10:06 +0100, Anton Ivanov wrote:
> On 22/09/2023 09:41, Johannes Berg wrote:
> > > Yes, but when does the fork actually happen?
> > >
> > Looking further at this, now I'm confused as to why it doesn't happen
> > _all_ the time.
&
On Fri, 2023-09-22 at 11:10 +0200, Johannes Berg wrote:
> On Fri, 2023-09-22 at 10:06 +0100, Anton Ivanov wrote:
> > On 22/09/2023 09:41, Johannes Berg wrote:
> > > > Yes, but when does the fork actually happen?
> > > >
> > > Looking further at this, no
On Fri, 2023-09-22 at 10:19 +0100, Anton Ivanov wrote:
> >
> > So maybe that works - perhaps with a big comment?
>
> Ack. Will add this to the patch and run it through its paces.
>
We can also just get rid of it entirely:
diff --git a/arch/um/include/asm/mmu_context.h
b/arch/um/include/asm/mm
On Fri, 2023-09-22 at 11:51 +0200, Johannes Berg wrote:
> On Fri, 2023-09-22 at 10:19 +0100, Anton Ivanov wrote:
> > >
> > > So maybe that works - perhaps with a big comment?
> >
> > Ack. Will add this to the patch and run it through its paces.
> >
>
From: Johannes Berg
While enabling PREEMPT on UML, we found that the call to
force_flush_all() cannot be done where it is, it sleeps
while atomic.
Further investigation shows that all this seems at least
a bit roundabout and possibly wrong wrong in the first
place - we copy from the 'cu
On Fri, 2023-09-22 at 11:55 +0100, Anton Ivanov wrote:
> On 22/09/2023 10:55, Johannes Berg wrote:
> > On Fri, 2023-09-22 at 11:51 +0200, Johannes Berg wrote:
> > > On Fri, 2023-09-22 at 10:19 +0100, Anton Ivanov wrote:
> > > > > So maybe that works - perhaps with
>
> 4. UML TLB flush is also invoked during a fork. This happens
> with interrupts and preempt disabled which disagrees with the
> standard mm locking via rwsem. The mm lock for this code path
> had to be replaced with an rcu.
For the record, even if I figured out this gets rid of the complaints,
On Fri, 2023-09-22 at 14:41 +0100, Anton Ivanov wrote:
> On 22/09/2023 12:16, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > While enabling PREEMPT on UML, we found that the call to
> > force_flush_all() cannot be done where it is, it sleeps
> > while atomi
On Fri, 2023-09-22 at 13:16 +0200, Johannes Berg wrote:
>
> - /* Set parent's instruction pointer to start of clone-stub */
> - thread_regs[REGS_IP_INDEX] = STUB_CODE +
> - (unsigned long) stub_clone_handler -
> -
On Fri, 2023-09-22 at 13:16 +0200, Johannes Berg wrote:
> Note that this fixes what seems like an issue - we look
> at current->mm when we copy, but that doesn't seem right
> in the case of clone() without copying the MM. This is
> probably saved by the forced flush later
On Fri, 2023-09-22 at 14:41 +0100, Anton Ivanov wrote:
>
> It is nearly twice slower than the current approach on a find /usr -type f
> -exec cat {} > /dev/null \;
>
Btw, I cannot reproduce that at all - seems about the same in my tests?
Is there anything special in your setup?
Or maybe it's
On Fri, 2023-09-22 at 21:08 +0100, Anton Ivanov wrote:
> On 22/09/2023 20:41, Johannes Berg wrote:
> > On Fri, 2023-09-22 at 14:41 +0100, Anton Ivanov wrote:
> > >
> > > It is nearly twice slower than the current approach on a find /usr -type
>
This shouldn't pessimize since we keep copy_context_skas0() and
the setup there, but still clean up the code there to not rely on
current, and move the force_flush_all() to a more appropriate
place, which fixes the issue with that in the fork_handler().
johannes
From: Johannes Berg
This function gets a context that's already copied from
the old context if making a copy, or memset to 0 if not.
This means we don't need to play games with current,
even if those games are OK now since dup_mm() is only
ever called with current->mm as the source.
From: Johannes Berg
The reason to flush here is to resynchronize the mm after
a copy. For exec we don't need to since flush_thread()
will anyway clear everything.
Thus, we can just do this in arch_dup_mmap(), since when
that's invoked, the new mm has been setup sufficiently.
This isn
From: Johannes Berg
There's really not much value in having this as a
separate lock, and having it makes it harder to
clean up the init_new_context() semantics to not
rely on 'current', even if dup_mm() is really only
called with 'current->mm' as the source
On Sat, 2023-09-23 at 06:29 +0100, Anton Ivanov wrote:
>
> One more thing. Is your find "real" /bin/find or busybox.
Yeah, definitely real find, it's my normal host system with hostfs after
all :)
johannes
___
linux-um mailing list
linux-um@lists.infr
On Mon, 2023-09-25 at 14:29 +0100, Anton Ivanov wrote:
> I have rebased the preempt patch on top of these series.
>
> PREEMPT works with some performance decrease.
>
> VOLUNTARY deadlocks early in boot around the time it starts loading modules.
>
> non-preemptible deadlocks very early in boot.
>
On Mon, 2023-09-25 at 15:27 +0100, Anton Ivanov wrote:
> On 25/09/2023 14:33, Johannes Berg wrote:
> > On Mon, 2023-09-25 at 14:29 +0100, Anton Ivanov wrote:
> > > I have rebased the preempt patch on top of these series.
> > >
> > > PREEMPT
From: Johannes Berg
I removed all the users of this some time ago, but
evidently forgot the pointers. Remove them from the
data structure too.
Fixes: bfc58e2b98e9 ("um: remove process stub VMA")
Signed-off-by: Johannes Berg
---
arch/um/include/asm/mmu.h | 1 -
1 file changed,
On Tue, 2023-09-26 at 13:16 +0100, Anton Ivanov wrote:
>
> For the time being it is mostly negative :)
Oh well :)
> 1. The performance after the mm patch is down. By 30-40% on my standard bench.
For the record, you mean this three-patch series that we're discussing
in the thread of?
Btw, Benj
On Sat, 2023-10-07 at 08:51 +0800, Ma Ke wrote:
> In vector_mmsg_rx, to avoid an unexpected result returned by
> pskb_trim, we should check the return value of pskb_trim().
And how exactly do you propose pskb_trim() will return anything but 0 in
this scenario?
Please. If you have a static checker
On Fri, 2023-10-20 at 12:38 +0200, Benjamin Beichler wrote:
>
> Can you explain, why a time travel handler for stdin may be bad? It
> sounds like you want to avoid it, but I see no immediate problem.
>
I need to read the thread, but this one's easy ;-)
The thing is that on such a channel you d
On Fri, 2023-10-20 at 14:06 +0200, Benjamin Beichler wrote:
> Am 20.10.2023 um 13:39 schrieb Johannes Berg:
> > On Fri, 2023-10-20 at 12:38 +0200, Benjamin Beichler wrote:
> > >
> > > Can you explain, why a time travel handler for stdin may be bad? It
> > > sou
On Fri, 2023-10-20 at 14:20 +0200, Johannes Berg wrote:
>
> Yes but you need to schedule for the interrupt, and you don't
> necessarily know what 'current time' is at interrupt time.
>
> So let's say you have "something" that's scheduled to r
On Fri, 2023-10-20 at 14:43 +0200, Benjamin Beichler wrote:
> > > Yes but you need to schedule for the interrupt, and you don't
> > > necessarily know what 'current time' is at interrupt time.
> > >
> > > So let's say you have "something" that's scheduled to run at times
> > > - 1000
> > > - 2
On Fri, 2023-10-20 at 14:58 +0200, Benjamin Beichler wrote:
> > On Fri, 2023-10-20 at 14:06 +0200, Benjamin Beichler wrote:
> > > Am 20.10.2023 um 13:39 schrieb Johannes Berg:
> > > > On Fri, 2023-10-20 at 12:38 +0200, Benjamin Beichler wrote:
> > > > >
On Fri, 2023-10-20 at 17:47 +0200, Benjamin Beichler wrote:
>
> I think, I get now, why I don't have this Problem: My virtio simulation
> and my controller/simulation-master are tightly coupled and indeed the
> same process. When I create a new event for the UML-instance, it is
> anticipated in
On Mon, 2023-10-23 at 07:08 +, Vincent Whitchurch wrote:
> On Fri, 2023-10-20 at 16:47 +0200, Vincent Whitchurch wrote:
> > In basic time travel mode, I sometimes see "time goes backwards" panics
> > like the one below:
> >
> > Kernel panic: time-travel: time goes backwards 16168934492 ->
On Wed, 2023-10-25 at 11:55 +, Vincent Whitchurch wrote:
> On Mon, 2023-10-23 at 09:33 +0200, Johannes Berg wrote:
> > Do you have a specific workload that tends to reproduce this?
>
> I've been seeing it when running roadtest, but it's easily reproducible
> withou
On Wed, 2023-10-25 at 21:51 +0200, Johannes Berg wrote:
> On Wed, 2023-10-25 at 11:55 +, Vincent Whitchurch wrote:
> > On Mon, 2023-10-23 at 09:33 +0200, Johannes Berg wrote:
> > > Do you have a specific workload that tends to reproduce this?
> >
> > I've b
From: Johannes Berg
In 'basic' time-travel mode (without =inf-cpu or =ext), we
still get timer interrupts. These can happen at arbitrary
points in time, i.e. while in timer_read(), which pushes
time forward just a little bit. Then, if we happen to get
the interrupt after calculating th
On Wed, 2023-10-25 at 22:02 +0200, Johannes Berg wrote:
> On Wed, 2023-10-25 at 21:51 +0200, Johannes Berg wrote:
> > On Wed, 2023-10-25 at 11:55 +, Vincent Whitchurch wrote:
> > > On Mon, 2023-10-23 at 09:33 +0200, Johannes Berg wrote:
> > > > Do you have a s
From: Johannes Berg
In 'basic' time-travel mode (without =inf-cpu or =ext), we
still get timer interrupts. These can happen at arbitrary
points in time, i.e. while in timer_read(), which pushes
time forward just a little bit. Then, if we happen to get
the interrupt after calculating th
On Thu, 2023-10-26 at 07:23 +, Vincent Whitchurch wrote:
> > @@ -839,9 +863,7 @@ static u64 timer_read(struct clocksource *cs)
> > */
> > if (!irqs_disabled() && !in_interrupt() && !in_softirq() &&
> > !time_travel_ext_waiting)
> > - ti
On Thu, 2023-10-26 at 08:49 +, Vincent Whitchurch wrote:
> On Thu, 2023-10-26 at 09:38 +0200, Johannes Berg wrote:
> > On Thu, 2023-10-26 at 07:23 +, Vincent Whitchurch wrote:
> > > > @@ -839,9 +863,7 @@ static u64 timer_read(s
On Fri, 2023-10-27 at 16:05 +0200, Benjamin Beichler wrote:
>
> As I said, I'm also preparing some patches, therefore my few bits about
> those problems:
>
> - we noticed, that those backward running time is mostly created by the
> "unprotected" access to the variables of the time travel event
On Fri, 2023-10-27 at 17:32 +0200, Benjamin Beichler wrote:
> Am 27.10.2023 um 16:45 schrieb Johannes Berg:
> > On Fri, 2023-10-27 at 16:05 +0200, Benjamin Beichler wrote:
> > > - besides this, when you look into local_irq_save for um, this does
> > > not really dea
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> The UBD driver employs multiple threads to enhance block device accesses
> in userspace. These threads communicate via pipes and are triggered by
> interrupts that utilize the SIGIO handler.
>
> However, in TT mode, both inf-cpu and ext
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> This change permits interrupts on serial lines in time travel mode,
> especially in external mode. However, these interrupts are processed
> with the simple handler that does not provide any acknowledgment.
>
Yeah... we had this discus
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> Although the information for the next requested time was already sent in
> a prior message, this change introduces the otherwise unused time
> variable in the TT message. This addition enables an extra consistency
> check and can otherwi
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> The number of UM_TIMETRAVEL_REQUEST msgs is tried to reduced, if they
> are redundant via the time_travel_ext_prev_request_valid flag.
>
This ... doesn't parse so well. I think I get what you're trying to say,
but it's a bit awkward?
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> Allow the so called Calendar (or simulation master) to request the
> latest timetravel event. This can be used in situations, where the
> former request message from UML to Calendar was missed.
How ... is it possible to _miss_ a message
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> When the timetravel ext modus is used, accessing the timetravel event
> list can be interrupted by a message on the timetravel socket in the
> SIGIO signal handler. This interruption can potentially modify the event
> list, leading to ra
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> Given the presence of numerous timer_read calls in well-behaved code
> within the kernel and userspace, particularly those that do not employ
> busy loops, we introduce a delay in reading the timer only after several
> consecutive attemp
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> This slows down external TT-mode as more simulation roundtrips are
> required, and it unnecessarily affects the determinism and accuracy of
> the simulation.
I still don't think this is really true, it doesn't really affect
determinism?
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> In time travel mode, the internal time is only advanced at discrete
> synchronization points, while the TSC register continuously increases.
> Although the TSC registers remain accessible, we remove the TSC flags to
> indicate to program
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> The Timetravel socket can be read from the SIGIO handler, which may
> catch a RUN message that was expected to be received in the wait loop.
>
> It can happen that the device simulation only "created" one interrupt,
> but an uncertain (
On Fri, 2023-11-10 at 17:53 +0100, Benjamin Beichler wrote:
> >
> > At least in my mental model this is broken because the sender of the
> > event basically has to prepare the calendar for it happening, which
> > feels ... odd.
> Actually, for me, this would make kind of sense.
I'm not sure I ag
On Fri, 2023-11-10 at 17:23 +0100, Benjamin Beichler wrote:
> Am 06.11.2023 um 21:33 schrieb Johannes Berg:
> >
> >
> > On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> > > Allow the so called Calendar (or sim
On Fri, 2023-11-10 at 16:54 +0100, Benjamin Beichler wrote:
> Am 06.11.2023 um 21:51 schrieb Johannes Berg:
> > On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> > > This slows down external TT-mode as more simulation roundtrips are
> > > required, and i
So I guess now you reminded me of this thread ...
> The Timetravel socket can be read from the SIGIO handler, which may
> catch a RUN message that was expected to be received in the wait loop.
>
> It can happen that the device simulation only "created" one interrupt,
> but an uncertain (i.e., har
compromise, there's no
need to have any core changes and it solves the main use
case we have for it.
Signed-off-by: Mordechay Goodstein
Signed-off-by: Johannes Berg
---
arch/um/include/shared/timetravel.h | 9 +
arch/um/kernel/time.c | 59 +
a
From: Johannes Berg
For the upcoming shared-memory time-travel external
optimisations, we need to be able to mmap/mremap
(and on error munmap). Add the necessary OS calls.
Signed-off-by: Johannes Berg
---
arch/um/include/shared/os.h | 3 +++
arch/um/os-Linux/file.c | 28
From: Johannes Berg
Change os_rcv_fd() to os_rcv_fd_msg() that can more generally
receive any number of FDs in any kind of message.
Signed-off-by: Johannes Berg
---
arch/um/drivers/port_kern.c | 14 +
arch/um/drivers/xterm.c | 2 +-
arch/um/drivers/xterm_kern.c | 13
So I've been mentioning the shared memory part, but because it
(mechanically, not semantically) depends on the broadcast
messages we use to separate tests, I've included those patches
here as well.
As for the shared memory part, the calendar/controller we have
already implements that protocol, see
1 - 100 of 352 matches
Mail list logo
