To be used sparingly, but still interesting in the case of small
firmwares designed to reproduce bugs in QEMU IDE.
Signed-off-by: John Snow <jsnow@redhat.com>
---
hw/ide/core.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 6235bdf..29848ff 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -2251,6 +2251,8 @@ void ide_data_writew(void *opaque, uint32_t addr, uint32_t val)
IDEState *s = idebus_active_if(bus);
uint8_t *p;
+ trace_ide_data_writew(addr, val, bus, s);
+
/* PIO data access allowed only when DRQ bit is set. The result of a write
* during PIO out is indeterminate, just ignore it. */
if (!(s->status & DRQ_STAT) || ide_is_pio_out(s)) {
@@ -2296,6 +2298,8 @@ uint32_t ide_data_readw(void *opaque, uint32_t addr)
s->status &= ~DRQ_STAT;
s->end_transfer_func(s);
}
+
+ trace_ide_data_readw(addr, ret, bus, s);
return ret;
}
@@ -2305,6 +2309,8 @@ void ide_data_writel(void *opaque, uint32_t addr, uint32_t val)
IDEState *s = idebus_active_if(bus);
uint8_t *p;
+ trace_ide_data_writel(addr, val, bus, s);
+
/* PIO data access allowed only when DRQ bit is set. The result of a write
* during PIO out is indeterminate, just ignore it. */
if (!(s->status & DRQ_STAT) || ide_is_pio_out(s)) {
@@ -2335,7 +2341,8 @@ uint32_t ide_data_readl(void *opaque, uint32_t addr)
/* PIO data access allowed only when DRQ bit is set. The result of a read
* during PIO in is indeterminate, return 0 and don't move forward. */
if (!(s->status & DRQ_STAT) || !ide_is_pio_out(s)) {
- return 0;
+ ret = 0;
+ goto out;
}
p = s->data_ptr;
@@ -2350,6 +2357,9 @@ uint32_t ide_data_readl(void *opaque, uint32_t addr)
s->status &= ~DRQ_STAT;
s->end_transfer_func(s);
}
+
+out:
+ trace_ide_data_readl(addr, ret, bus, s);
return ret;
}
--
2.9.4
On 08/08/2017 01:33 PM, John Snow wrote: > To be used sparingly, but still interesting in the case of small > firmwares designed to reproduce bugs in QEMU IDE. > > Signed-off-by: John Snow <jsnow@redhat.com> > --- > hw/ide/core.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/hw/ide/core.c b/hw/ide/core.c > index 6235bdf..29848ff 100644 > --- a/hw/ide/core.c > +++ b/hw/ide/core.c > @@ -2251,6 +2251,8 @@ void ide_data_writew(void *opaque, uint32_t addr, uint32_t val) > IDEState *s = idebus_active_if(bus); > uint8_t *p; > > + trace_ide_data_writew(addr, val, bus, s); Umm, where's the trace-events addition for this? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On 08/08/2017 04:10 PM, Eric Blake wrote: > On 08/08/2017 01:33 PM, John Snow wrote: >> To be used sparingly, but still interesting in the case of small >> firmwares designed to reproduce bugs in QEMU IDE. >> >> Signed-off-by: John Snow <jsnow@redhat.com> >> --- >> hw/ide/core.c | 12 +++++++++++- >> 1 file changed, 11 insertions(+), 1 deletion(-) >> >> diff --git a/hw/ide/core.c b/hw/ide/core.c >> index 6235bdf..29848ff 100644 >> --- a/hw/ide/core.c >> +++ b/hw/ide/core.c >> @@ -2251,6 +2251,8 @@ void ide_data_writew(void *opaque, uint32_t addr, uint32_t val) >> IDEState *s = idebus_active_if(bus); >> uint8_t *p; >> >> + trace_ide_data_writew(addr, val, bus, s); > > Umm, where's the trace-events addition for this? > Accidentally traveled forward through time to patch 04.
On 08/08/2017 01:33 PM, John Snow wrote: > To be used sparingly, but still interesting in the case of small > firmwares designed to reproduce bugs in QEMU IDE. Is that because the trace would fire so frequently in normal usage that it will drown the user in noise? > > Signed-off-by: John Snow <jsnow@redhat.com> > --- > hw/ide/core.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > Reviewed-by: Eric Blake <eblake@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On 08/08/2017 03:30 PM, Eric Blake wrote: > On 08/08/2017 01:33 PM, John Snow wrote: >> To be used sparingly, but still interesting in the case of small >> firmwares designed to reproduce bugs in QEMU IDE. > > Is that because the trace would fire so frequently in normal usage that > it will drown the user in noise? > >> >> Signed-off-by: John Snow <jsnow@redhat.com> >> --- >> hw/ide/core.c | 12 +++++++++++- >> 1 file changed, 11 insertions(+), 1 deletion(-) >> > > Reviewed-by: Eric Blake <eblake@redhat.com> Argh. I had two compose windows open at once. R-b is only valid if you fix the time-traveling trace-events changes :) -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On 08/08/2017 04:30 PM, Eric Blake wrote: > On 08/08/2017 01:33 PM, John Snow wrote: >> To be used sparingly, but still interesting in the case of small >> firmwares designed to reproduce bugs in QEMU IDE. > > Is that because the trace would fire so frequently in normal usage that > it will drown the user in noise? > Yeah, and it's of little use for a real guest due to the volume and relative unimportance of what that data actually is >> >> Signed-off-by: John Snow <jsnow@redhat.com> >> --- >> hw/ide/core.c | 12 +++++++++++- >> 1 file changed, 11 insertions(+), 1 deletion(-) >> > > Reviewed-by: Eric Blake <eblake@redhat.com> >
© 2016 - 2026 Red Hat, Inc.