On Fri Mar 1, 2024 at 5:55 PM CST, Edgar E. Iglesias wrote:
> Hi,
>
> I don't have great answers unfortunately...
>
> We haven't been super consistent with these things but on the ZynqMP we
> sometimes require the user to apply ROM behaviour using -device loader on
> the command-line (not great for
When the CPU is reset using PSS_RST_CTRL in the SLCR, bit 19 in
REBOOT_STATUS should be set.
Refer to page 1602 of the Xilinx Zynq 7000 Technical Reference Manual.
Signed-off-by: Gregory Anders
---
hw/misc/zynq_slcr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/misc/zynq_slcr.c b
people to use it to build a native QEMU.
>
> Rename it so it follows the same non-arch pattern of the other distro
> containers.
>
> Signed-off-by: Alex Bennée
> Cc: Anders Roxell
I tried it on my arm machine and it worked as expected.
And this should work for me
Tes
kernel (29s->24s).
>
> Signed-off-by: Alex Bennée
> Cc: Arnd Bergmann
> Cc: Anders Roxell
Tested-by: Anders Roxell
> ---
> target/arm/cpu_tcg.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu
t their problems are, rather
> than just assume that a container build is the solution.
Right now we use QEMU from Debian, and we miss new
architectural feature's that gets into QEMU. Our plan is to do:
1. running the latest QEMU with all the new architectual feature's.
2. helping out finding regressions in QEMU and/or the kernel, when
different kernels are booted with different QEMU versions.
If the hub.docker.com/u/qemu namespace could be used to store all the
different QEMU builds. With that we can get use of the latest architectural
feature's, also tri to find if the kernel regressed or if its QEMU that
regressed.
Cheers,
Anders
Typo. I meant that I've tried -netdev socket, not -device socket
On Thu, Jun 2, 2022, at 10:25 AM, Anders Pitman wrote:
> I'm trying to set up one guest as a SMB file server, and connect to it from
> several other guests. I tried using -device socket listen/connect, but it
>
her guests shouldn't be able
to communicate with anyone but the file server. Would I have to set up a
separate network interface on the server for each guest, or is there another
way to do this?
Thanks,
//anders
p is
significant, I would be interested in taking a crack at adding Windows support.
Thanks,
//anders
[0]: http://blog.vmsplice.net/2021/10/a-new-approach-to-usermode-networking.html
I'm running QEMU on a Windows host with multiple Linux guest VMs. I'm trying to
share a host directory with all the guests.
As I understand it, the way to do this with Linux hosts would be to configure a
9p share[0]. However, it appears that 9p support for Windows hosts is currently
a work in p
wrong?
Thanks,
//anders
On Wed, Apr 20, 2022, at 2:21 PM, Daniel Henrique Barboza wrote:
>
>
> On 4/20/22 16:08, Anders Pitman wrote:
> > I noticed in the 7.0 changelog that libslirp might be removed as a
> > submodule in the future. Since user networking is very important f
I noticed in the 7.0 changelog that libslirp might be removed as a submodule in
the future. Since user networking is very important for my project, I'm
wondering if this is simply an implementation detail, or if there are plans to
eventually remove slirp support entirely from QEMU (which would b
he dependencies themselves.
>
> We disable the registry because we currently don't have multi-arch
> support there.
>
> Signed-off-by: Alex Bennée
> Cc: Anders Roxell
Thank you for doing this Alex,
Tested-by: Anders Roxell
Cheers,
Anders
> ---
> tests/docker/Makef
I've tested the patch against the FreeRTOS example. An the patch seems
to make the example run.
The FreeRTOS sample now crash for other reasons. But I consider the
issue resolved.
/Anders
On 03/12/2015 02:45 PM, Peter Maydell wrote:
> Proposed patch: http://patchwork.ozlabs.org/patc
guest code, which I did :-), but shouldn't qemu
reflect the behaviour of the implemented hardware?
So it is "unpredictable" in the same way?
I'will note the FreeRTOS people they have a bad implementation of their
SVC handler for Cortex M3
Thanks for the help.
/Anders
--
You
Public bug reported:
This was observed in qemu v2.1.3, running a sample app from
FreeRTOS(FreeRTOSV7.5.2/FreeRTOS/Demo/CORTEX_LM3S_Eclipse/RTOSDemo)
In the sample code compiled with arm-none-eabi-gcc , version 4.8.2
(4.8.2-14ubuntu1+6) .
qemu seems to be executing the wrong instrunction aft
Changes so translation of remote address to the host's ip address in
the virtual network happens for all addresses in the 127.0.0.0/8
network, not just 127.0.0.1.
This fixes so that hostfwd bound to addresses such as 127.0.0.2 works.
Signed-off-by: Anders Waldenborg
---
On Fri, Jul 13, 20
Changes so translation of remote address to the host's ip address in
the virtual network happens for all addresses in the 127.0.0.0/8
network, not just 127.0.0.1.
This fixes so that hostfwd bound to addresses such as 127.0.0.2 works.
Signed-off-by: Anders Waldenborg
---
Thanks for the r
Changes so translation of remote address to the host's ip address in
the virtual network happens for all addresses in the 127.0.0.0/8
network, not just 127.0.0.1.
This fixes hostfwd bound to addresses such as 127.0.0.2 works
Signed-off-by: Anders Waldenborg
---
slirp/main.h |1 +
multitos and atari.
I will, in the realm of about a year (or less) start this project, when I
made a crew to work with.
(today is 24 juli 2011)
If you are interested (or not) please contact me!
Best Regards
Anders Lindström
, if the canvas is not visible? How
about some infrastructure for pausing the update completely? I think
that could also be used for VNC displays, when no client is connected.
Anders.
ork there.
[1] The slirp file descriptors are not included yet.
Anders.
diff --git a/vl.c b/vl.c
index c87e8bc..ff8ceef 100644
--- a/vl.c
+++ b/vl.c
@@ -1148,6 +1148,25 @@ static int timer_load(QEMUFile *f, void *opaque, int
version_id)
return 0;
}
+#ifndef _WIN32
+static void host
myself yet, as the HPET
and RTC timers both do not work on my system. If I get feedback that
this approach is not good, I will not spend the time on getting those
timers to behave.
Best regards,
Anders.
diff --git a/vl.c b/vl.c
index c87e8bc..d94302d 100644
--- a/vl.c
+++ b/vl.c
@@ -1240,7
Anders Melchiorsen <[EMAIL PROTECTED]> writes:
> --- a/qemu/vl.c
> +++ b/qemu/vl.c
> @@ -4902,13 +4902,6 @@ static void dumb_resize(DisplayState *ds, int w, int h)
> {
> }
>
> -static void dumb_refresh(DisplayState *ds)
> -{
> -#if defined(CONFIG_SDL)
However, your gut feeling
alone does not give me much to work with.
Anders.
an make the function into a noop made
me quite confident that nothing globally important was going on with
the refresh.
Cheers,
Anders.
Andrzej Zaborowski <[EMAIL PROTECTED]> writes:
> Log message:
> Reduce redundant timer ticks in VNC, by Anders Melchiorsen.
>
> CVSWeb URLs:
> http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemu&r1=1.31&r2=1.32
That is great, thanks. However, I ha
PowerTOP, as this
really is a micro-optimization. On the other hand, this change
eliminates the last host-induced periodic timer in my kvm setup, so it
seems worth the trouble.
Please comment, does it make sense?
Anders.
diff --git a/qemu/hw/mc146818rtc.c b/qemu/hw/mc146818rtc.c
index e1e6427
host_alarm_handler(), to make sure it is always done. This broke kvm.
Cheers,
Anders.
diff --git a/vl.c b/vl.c
index 129166d..a7d9021 100644
--- a/vl.c
+++ b/vl.c
@@ -822,7 +822,7 @@ struct qemu_alarm_timer {
};
#define ALARM_FLAG_DYNTICKS 0x1
-#define ALARM_FLAG_MODIFIED 0x2
+#define
re-apply the reverted one).
Anders.
diff --git a/qemu/vl.c b/qemu/vl.c
index 28c5df4..000df7e 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -850,6 +850,7 @@ struct qemu_alarm_timer {
};
#define ALARM_FLAG_DYNTICKS 0x1
+#define ALARM_FLAG_EXPIRED 0x2
static inline int alarm_has_dynticks(s
>>>>> Redundant timer rearm optimisation by Anders Melchiorsen.
> I'm merging qemu-cvs into the kvm repository now, and with this commit
> in, kvm will hang after about a minute. Attaching to it with gdb or
> strace will cause it to resume, so this is very like
only fire when a client is actually
connected to the VNC server.
Best regards,
Anders.
--- a/qemu/vnc.c
+++ b/qemu/vnc.c
@@ -493,6 +493,8 @@ static void vnc_update_client(void *opaque)
int saved_offset;
int has_dirty = 0;
+vga_hw_update();
+
vnc_set_bits(width_mask, (vs
Paul Brook wrote:
Redundant timer rearm optimisation by Anders Melchiorsen.
I think this is incorrect.
When a timer is modified, we need to rearm the host timer immediately. We can
not wait for the old timer to fire, or for execution to fall back to the
main_loop_wait. Consider
.
Best regards,
Anders.
diff --git a/qemu/vl.c b/qemu/vl.c
index 2cd580d..924736e 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -816,6 +816,7 @@ struct qemu_alarm_timer {
};
#define ALARM_FLAG_DYNTICKS 0x1
+#define ALARM_FLAG_MODIFIED 0x2
static inline int alarm_has_dynticks(struct
timer_gettime
0.000.00 0 162 clock_gettime
-- --- --- - -
100.000.12 408461 total
Cheers,
Anders.
diff --git a/qemu/vl.c b/qemu/vl.c
index 30c9537..8d67314 100644
--- a/qemu/vl.c
0013 72249 8188 total
I am not so sure about this one, so comments are appreciated.
Best regards,
Anders.
diff --git a/qemu/vl.c b/qemu/vl.c
index 2cd580d..924736e 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -816,6 +816,7 @@ struct qemu_alarm_timer {
};
#defi
-- --- --- - -
100.000.012623 82421 8119 total
Patch (based on kvm-userspace git) attached.
Cheers,
Anders.
diff --git a/qemu/vl.c b/qemu/vl.c
index 80ceb2f..2cd580d 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -1063,7 +1063,6 @@ static void qemu_run_timers(QEMUTimer **ptimer_head, int64_t
Hi all!
I think a found a workaround for the windows XP problem:
"A problem is preventing Windows from accurately checking the
license for this computer. Error code: 0x800703e6."
I had this problem with my XP version. I started in
safe mode without network as recommended in your documentati
37 matches
Mail list logo
