Please find the binary attached.
I have been trying several versions and it looks like the regression
occured between v2.8.0 and v2.9.0.
** Attachment added: "Binary showing systick /timers/icount problem"
https://bugs.launchpad.net/qemu/+bug/1754038/+attachment/5072853/+files/hello.bin
--
I just tested the patch and it resolves this problem. Thanks!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1755479
Title:
Cortex M:qemu abort with optimized code and icount
Status in QEMU:
New
Public bug reported:
A basic program runs fine if compiled with flag -O0 with gcc, but triggers a
qemu abort when compiled with -O1 and run with icount:
"qemu: fatal: IO on conditional branch instruction"
I also noticed the problem on C source like this with -O0:
"int foo = *bar; bar++;" : OK
I finally implemented a workaround to correct the problem:
in cpus.c : qemu_start_warp_timer(), in the "if (deadline > 0) { ... }"
part, I added:
CPUState *cpu;
CPU_FOREACH(cpu) {
atomic_mb_set(>exit_request, 1);
}
I do not understand more than 5% of the code
The workaround I described above is actually not the good one, because
of this check occurring just before:
if (!all_cpu_threads_idle()) {
return;
}
The exit request setting must be done before, so my code looks like
this:
CPUState *cpu;
CPU_FOREACH(cpu) {
I tried to insert an ISB in the loop but I get more or less the same
result.
However, I guess from your response that I did not explain the problem
well enough. I understand that qemu will not be cycle accurate, however,
here, we are not even "one million cycles accurate"! The counter would
have
Ok I spent more time trying to identify the commits giving problem.
So before 8d04fb5, qemu is executing the binary as expected:
setup timer
cnt 007a --7
cnt 006998a2 --7
cnt 00566479 --7
cnt 0043304f --7
cnt 002ffc26 --7
cnt 001cc7fd --7
Public bug reported:
When running this kind of code with qemu:
static void SysTickISR(void)
{
printf("SysTick\n");
}
void main()
{
volatile int i, j;
printf("setup timer\n");
*(uint32_t*) 0xE000E014 = 0x8F; //reload value
*(uint32_t*) 0xE000E018 = 0;
Hi Peter,
I just tested your patch, I confirm it is also working on my side. Many
thanks.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1754038
Title:
ARM M: Systick first wrap delayed
This patch consolidates the bit twidling involved in reading and
writing the time registers to four functions that are used consistently.
This also has the effect of fixing bug 1090558.
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/mc146818rtc.c | 163
On 02/14/2013 10:30 AM, Paolo Bonzini wrote:
Nice. Do you have a testcase?
No, but the refactoring makes the code very easy to audit.
Please also test this patch with the two rtc-test patches at
http://thread.gmane.org/gmane.comp.emulators.qemu/188244.
I did and the tests pass.
First, the ds1338 code was in a poor state and never handled the 12 hour
clock correctly. My first patch failed to fully fix the problem so I had
to write a second one, but at no point did Peter or I introduce a
regression, quite the opposite.
Second, I don't know where you got the idea that
On 02/15/2013 12:24 PM, Andreas Färber wrote:
The expected answer would've been take guest X and do Y to see Z, or
better to extend the existing qtest cases to prove something was broken
before and fixed afterwards and to avoid the same bug being reintroduced
later.
If we are talking about
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 156 ---
1 file changed, 95 insertions(+), 61 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 1da0f96..5a93fb6 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
Per the datasheet, the mapping between 12 and 24 hours modes is:
0 - 12 PM
1-12 - 1-12 AM
13-23 - 1-11 PM
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/hw
Minor fixes in the handling of the RTC registers.
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 1274b22..1fb152e 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
Per the datasheet, the OSF bit in the control register can only be
cleared. Attempts to set it have no effect. Implement this.
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
) is not supposed to set these bits it is safer to check
anyway. In order not to duplicate this logic I thus chose to enforce it
at read time.
Note that currently we don't preserve what the user sends in (2). We
will have to once we support stopping the clock (CH bit).
Signed-off-by: Antoine Mathys barsa
Per the datasheet, the DATE (wday) register is user defined. Implement this.
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 8f85635..c502934 100644
--- a/hw
On 12/04/2012 06:42 PM, Peter Maydell wrote:
This looks good as far as the logic goes, but I think we could use
some symbolic constants for the 12-hour and PM bits rather than all
the literal 0x20 0x40 0x60. thanks -- PMM
I refrained from using symbolic constants for three reasons:
1. You
This is the second version of my series of patch to hw/ds1338.c
It should address the various points that were made. The main difference
with the previous version is that I dropped some stuff that will only be
useful once we implement clock enable/disable.
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index b576d56..faaa4a0 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -57,9 +57,9 @@ static void capture_current_time(DS1338State
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index faaa4a0..69018bc 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -17,6 +17,12 @@
*/
#define NVRAM_SIZE 64
+/* Flags definitions
Per the datasheet, the mapping between 12 and 24 hours modes is:
0 - 12 PM
1-12 - 1-12 AM
13-23 - 1-11 PM
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 0f88720..b4d5b74 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -179,6 +179,15 @@ static int ds1338_init(I2CSlave *i2c)
return 0
The previous patch has the side effect of clearing the control register.
That's already its proper power-on-reset value.
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/hw/ds1338.c b/hw
Per the datasheet, the DAY (wday) register is user defined. Implement this.
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 319c341..c5cee99 100644
--- a/hw
On 12/12/2012 01:05 PM, Peter Maydell wrote:
I think we need to reset ptr and addr_byte too...
The initial value of the register pointer is unspecified.
addr_byte is only used when receiving user data. It is written in
ds1338_event() then read in ds1338_send(). Setting it in ds1338_reset()
It's true that it probably doesn't make much difference, but
both the addr_byte and ptr are part of the migration state
listed in the vmstate struct. I think it is cleaner and
more straightforward to reason about if resetting the
device returns it to an exact known state. The state may be
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index faaa4a0..69018bc 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -17,6 +17,12 @@
*/
#define NVRAM_SIZE 64
+/* Flags definitions
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index b576d56..faaa4a0 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -57,9 +57,9 @@ static void capture_current_time(DS1338State
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index d2f52fc..94a2f54 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -125,7 +125,8 @@ static int ds1338_send
Per the datasheet, the mapping between 12 and 24 hours modes is:
0 - 12 PM
1-12 - 1-12 AM
13-23 - 1-11 PM
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions
Per the datasheet, the DAY (wday) register is user defined. Implement this.
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 94a2f54..1aefa3b 100644
--- a/hw
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 51 ++-
1 file changed, 38 insertions(+), 13 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index b576d56..d2f52fc 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -17,6
Oops. There was a problem in the patch. Resending the series.
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index b576d56..faaa4a0 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -57,9 +57,9 @@ static void capture_current_time(DS1338State
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index faaa4a0..69018bc 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -17,6 +17,12 @@
*/
#define NVRAM_SIZE 64
+/* Flags definitions
Per the datasheet, the mapping between 12 and 24 hours modes is:
0 - 12 PM
1-12 - 1-12 AM
13-23 - 1-11 PM
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 12
1 file changed, 12 insertions(+)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 0f88720..d2f52fc 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -179,6 +179,17 @@ static int ds1338_init(I2CSlave *i2c)
return
Per the datasheet, the DAY (wday) register is user defined. Implement this.
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index 94a2f54..1aefa3b 100644
--- a/hw
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
index d2f52fc..94a2f54 100644
--- a/hw/ds1338.c
+++ b/hw/ds1338.c
@@ -125,7 +125,8 @@ static int ds1338_send
On 12/13/2012 03:09 PM, Peter Maydell wrote:
I certainly will send further patches.
As you noticed I am new to git. Thanks for your patience and advice.
Public bug reported:
get_next_alarm() doesn't read the RTC_HOURS_ALARM field correctly.
- Bit 7 must be masked before conversion from BCD.
- Care must be taken to check the don't care condition before masking.
- The PM bit must be read from RTC_HOURS_ALARM, not from RTC_HOURS (as is done
in
The proper mapping between 24 hours and 12 hours modes is:
0 12 AM
1-111-11 AM
12 12 PM
13-23 1-11 PM
Fix code accordingly.
Signed-off-by: Antoine Mathys barsa...@gmail.com
---
hw/ds1338.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/ds1338.c
to be good. Which leads me to ask,
what should I do when I get such a failed access? What can I do so that qemu
somehow allocate or wire up the device access?
I work on x86_64 frontend and backend.
Thanks for your time,
Antoine.
to keep migration compatibility between qemu versions.
Thank you all,
--
Antoine 'xdbob' Damhet
signature.asc
Description: PGP signature
VM_CAP_ADJUST_CLOCK check instead of CPUID feature bits.
>
> Reported-by: Antoine Damhet
> Suggested-by: Paolo Bonzini
> Signed-off-by: Vitaly Kuznetsov
Tested-by: Antoine Damhet
> ---
> hw/i386/kvm/clock.c| 7 +--
> hw/i386/microvm.c | 2 +-
> hw/i386/pc.
; to always make sense to call KVM_GET_CLOCK/KVM_SET_CLOCK on migration.
> Use KVM_CAP_ADJUST_CLOCK check instead of CPUID feature bits.
>
> Reported-by: Antoine Damhet
> Suggested-by: Paolo Bonzini
> Signed-off-by: Vitaly Kuznetsov
> ---
> hw/i386/kvm/clock.c| 6 +-
going to do?
I guess that if the migration succeed (and the VMState keeps it's
initial value) the timestamp will be restored to 0 which is the current
behavior.
>
> Dave
[...]
--
Antoine 'xdbob' Damhet
signature.asc
Description: PGP signature
nk we need to remove all 'if (kvm_enabled())' checks from
> machine types as 'kvm=off' should not be related).
Indeed (I didn't look at the macro, it was just quick & dirty).
>
> --
> Vitaly
>
>
--
Antoine 'xdbob' Damhet
signature.asc
Description: PGP signature
On Wed, Sep 16, 2020 at 12:29:56PM +0100, Dr. David Alan Gilbert wrote:
> cc'ing in Vitaly who knows about the hv stuff.
Thanks
>
> * Antoine Damhet (antoine.dam...@blade-group.com) wrote:
> > Hi,
> >
> > We are experiencing timestamp rollbacks during live-migrati
On Wed, Sep 16, 2020 at 01:59:43PM +0200, Vitaly Kuznetsov wrote:
> "Dr. David Alan Gilbert" writes:
>
> > cc'ing in Vitaly who knows about the hv stuff.
> >
>
> cc'ing Marcelo who knows about clocksources :-)
>
> > * Antoine Damhet (ant
ion from an older VM;
> > > you'll have a kvm clock created here, but you won't load the kvm clock
> > > state from the migration stream - what is this clock going to do?
> >
> > This is not really a problem I believe: the clock was absent on the
> > source and things somehow worked for the guest so even if we don't
> > initialize kvmclock properly on the destination nothing bad is expected.
>
> OK.
>
> Dave
[...]
--
Antoine 'xdbob' Damhet
signature.asc
Description: PGP signature
From: Antoine Damhet
The `detect-zeroes=unmap` option may issue unaligned
`FALLOC_FL_PUNCH_HOLE` requests, raw block devices can (and will) return
`EINVAL`, qemu should then write the zeroes to the blockdev instead of
issuing an `IO_ERROR`.
Signed-off-by: Antoine Damhet
---
block/file-posix.c
From: Antoine Damhet
The `detect-zeroes=unmap` option may issue unaligned
`FALLOC_FL_PUNCH_HOLE` requests, raw block devices can (and will) return
`EINVAL`, qemu should then write the zeroes to the blockdev instead of
issuing an `IO_ERROR`.
Signed-off-by: Antoine Damhet
---
I am resending
On Mon, Jul 20, 2020 at 04:07:26PM +0200, Kevin Wolf wrote:
> Am 17.07.2020 um 15:56 hat antoine.dam...@blade-group.com geschrieben:
> > From: Antoine Damhet
> >
> > The `detect-zeroes=unmap` option may issue unaligned
> > `FALLOC_FL_PUNCH_HOLE` requests, raw block de
if the signature is found in any of the
exposed tables.
[1]:
https://lore.kernel.org/qemu-devel/1441220618-4750-1-git-send-email-rjo...@redhat.com/
--
Antoine 'xdbob' Damhet
On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> On Wed, Nov 25, 2020 at 01:32:51PM +, Richard W.M. Jones wrote:
> > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> > > Hello,
> > >
> > > We recently found out that som
On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:
> On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
> > On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> > > On Wed, Nov 25, 2020 at 01:32:51PM +, Richard W.M. Jones wro
On Thu, Nov 26, 2020 at 12:09:13PM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 26, 2020 at 05:34:50PM +0100, Antoine Damhet wrote:
> > On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote:
> > > On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote:
>
On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote:
> > On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:
> > > On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
>
ing GLOBAL_STATE_CODE in IO_CODE is allowed, since GSC callers are
> allowed to call IO_CODE.
>
> Resolves: #1272
>
> Signed-off-by: Emanuele Giuseppe Esposito
Tested-by: Antoine Damhet
> ---
> block/block-backend.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
--
Antoine 'xdbob' Damhet
signature.asc
Description: PGP signature
On Wed, Nov 16, 2022 at 10:52:20AM +, Daniel P. Berrangé wrote:
> On Tue, Nov 15, 2022 at 03:23:29PM +0100, antoine.dam...@shadow.tech wrote:
> > From: Antoine Damhet
> >
> > Since the TLS backend can read more data from the underlying QIOChannel
> > we introd
From: Antoine Damhet
The new `qcrypto_tls_session_check_pending` function allows the caller
to know if data have already been consumed from the backend and is
already available.
Signed-off-by: Antoine Damhet
---
crypto/tlssession.c | 14 ++
include/crypto/tlssession.h | 11
From: Antoine Damhet
At least with the TCP backend the tls implementation can stall because
the current notification mechanism is based on the readyness status of
the underlying file descriptor but gnutls can read all the data
available while the consumer has only handled part (eg: the TCP
From: Antoine Damhet
Since the TLS backend can read more data from the underlying QIOChannel
we introduce a minimal child GSource to notify if we still have more
data available to be read.
Signed-off-by: Antoine Damhet
Signed-off-by: Charles Frey
---
io/channel-tls.c | 66
> The docs for `g_source_add_child_source(source, child_source)` says
> "source will hold a reference on child_source while child_source is
> attached to it." Therefore, we should unreference the child source at
> `qio_channel_tls_read_watch()` after attaching it to `source`. Wit
done
> before sending bytes to a character device to see how much it can handle,
> so the s->max_size in tcp_chr_read() still contains the old value from the
> previous read. Let's make sure that we use the up-to-date value by calling
> tcp_chr_read_poll() again here.
>
> Fixes: ffda5db65a
Any chance to get this reviewed/applied any time soon ? It currently
does not build without it with gcc 4.6.0
On 29 April 2011 17:59, Marc-Antoine Perennou marc-anto...@perennou.com wrote:
pulse/simple.h does not include stdlib.h
We cannot use NULL since it may not be defined
Use 0 instead
On 4 June 2011 00:54, malc av1...@comtv.ru wrote:
On Sat, 4 Jun 2011, Aurelien Jarno wrote:
On Sat, Jun 04, 2011 at 01:57:23AM +0400, malc wrote:
On Fri, 3 Jun 2011, Aurelien Jarno wrote:
On Fri, Apr 29, 2011 at 05:59:19PM +0200, Marc-Antoine Perennou wrote:
pulse/simple.h does
On 10 June 2011 09:14, Markus Armbruster arm...@redhat.com wrote:
Peter Maydell peter.mayd...@linaro.org writes:
On 9 June 2011 18:44, Andreas Färber andreas.faer...@web.de wrote:
Am 09.06.2011 um 17:52 schrieb Marc-Antoine Perennou:
Manually including stddef.h or replacing NULL by 0 or (void
pulse/simple.h does not include stdlib.h
We cannot use NULL since it may not be defined
Use 0 instead
Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
---
configure |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index ea8b676
75 matches
Mail list logo
