[Qemu-devel] [PATCH]Fix two functions of the same name
It is funny that we have two sigbus_handler in our QEMU.(exec.c &
cpus.c)Change one's name.
Signed-off-by: Peace
---
cpus.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpus.c b/cpus.c
index dd7ac13..2a429e5 100644
--- a/cpus.c
+++ b/cpus.c
@@ -583,7 +583,7 @@ static void sigbus_reraise(void)
abort();
}
-static void sigbus_handler(int n, struct qemu_signalfd_siginfo *siginfo,
+static void default_sigbus_handler(int n, struct qemu_signalfd_siginfo
*siginfo,
void *ctx)
{
if (kvm_on_sigbus(siginfo->ssi_code,
@@ -598,7 +598,7 @@ static void qemu_init_sigbus(void)
memset(&action, 0, sizeof(action));
action.sa_flags = SA_SIGINFO;
-action.sa_sigaction = (void (*)(int, siginfo_t*, void*))sigbus_handler;
+action.sa_sigaction = (void (*)(int, siginfo_t*,
void*))default_sigbus_handler;
sigaction(SIGBUS, &action, NULL);
prctl(PR_MCE_KILL, PR_MCE_KILL_SET, PR_MCE_KILL_EARLY, 0, 0);
--
1.7.2.5
[Qemu-devel] HQEMU :Violations of the GPLLicenses?
Efficient and retargetable dynamic binary translation on multicores Author:Ding-Yong Hong; Jan-Jan Wu; Pen-Chung Yew; Wei-Chung Hsu; Chun-Chen Hsu; Pangfeng Liu; Chien-Min Wang; Yeh-Ching Chung IEEE Transactions on Parallel and Distributed Systems DOI: 10.1109/TPDS.2013.56 Year: March 2014 As mentioned in this article，HQEMU is based on QEMU,which is realesd under the GPL license.But you cannot find any line of its source codes. Is this group‘s behavior a violation of the GPL Licenses?
Re: [Qemu-devel] HQEMU :Violations of the GPLLicenses?
In fact I do ask them for anything(binaries /source codes/diff to QEMU) to verify their result,but I have got no any reply from their funny group.Maybe I should write comments to the journal (and) to request sth. for verifing.Or someone in their group can see this letter in maillist. Many papers said they can acclerate QEMU in a huge boost.(20x,e.g.)I read their papers carefully in order to find codes which are changed in their work.Let's take this paper for example. they published their work first on CGO'12(HQEMU: A Multi-Threaded and Retargetable Dynamic Binary Translator on Multicores).In their work,a counter was added in every basic block to detect hot traces.It's funny that they put this counter in their final codes as they said.They told us that HQEMU runs faster than QEMU.I myself added a counter just like theirs only for profiling.QEMU would run very very slow after putting a counter in every block . So I wanted to know how they overcome this. After waiting for 2 years,I found this paper published on I3E Trans. So I asked for sth. to verify again but still no reply 2014-06-26 19:09 GMT+08:00 Andreas Färber : > Hi, > > Am 25.06.2014 16:05, schrieb Lb peace: > > Efficient and retargetable dynamic binary translation on multicores > > Author:Ding-Yong Hong; Jan-Jan Wu; Pen-Chung Yew; Wei-Chung Hsu; > > Chun-Chen Hsu; Pangfeng Liu; Chien-Min Wang; Yeh-Ching Chung > > IEEE Transactions on Parallel and Distributed Systems > > DOI: 10.1109/TPDS.2013.56 > > Year: March 2014 > > > > > > As mentioned in this article，HQEMU is based on QEMU,which is realesd > > under the GPL license.But you cannot find any line of its source codes. > > Is this group‘s behavior a violation of the GPL Licenses? > > In general, if you want legal advice, talk to lawyers. :) > You're unlikely to find any on a development mailing list. > > But you can read through the GPL version 2.0 yourself, in particular > section 3: > http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html > > So, before you ask about GPL "violations", have you simply contacted > them by email and asked nicely whether they will provide you with the > sources matching that paper? As Peter says, if you don't have the > binaries, you have no legal right under the GPL to obtain the sources of > random software, but they might still do so. At least my former > university used to share its GPL sources for the benefit of paper > verification and (getting referenced by) follow-up projects, be it on > proceedings CDs or via download. > > Regards, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg >
[Qemu-devel] A grammar mistake in wiki
http://wiki.qemu.org/Features/PostCopyLiveMigration in description： “This is is yet” should be changed to "This is "Or "It is "
[Qemu-devel] Some mistakes（？）in wiki
http://wiki.qemu.org/Features/ResetAPI： system reseta hardware mechanism for setting or returning all hardware states to the initial conditions.* Use caseIn qemu, system_system_reset(). cold reset(power on reset)system reset following the application of power. * Use caseIn qemu, system_reset() in main().We might want to use this as a power cycle.When a device is hot plugged, the device should be cold reset too.* GuaranteeThe internal status must be same to qdev_init() + qdev_reset() warm resetsystem reset without cycling the supplied power.* Use caseIn qemu, system_reset() in main_loop(). There are many places which calls qemu_system_reset_request().Some state are retained across warm reset. Like PCIe AER, error reporting registers need to keep its contents across warm resetas OS would examine them and report it when hardware errors caused warm reset.==I can not found these functions: system_system_reset system_reset I think both of them refer to qemu_system_reset in vl.c .They are different just because they have different caller postions.
[Qemu-devel] [PATCH]Fix a error in mc146818rtc.c
If you use hwclock in guest os ,you will find the result of hwclock isn't
changed after changing host os's clock.
I find this issue is generated in this patch:
http://lists.gnu.org/archive/html/qemu-devel/2013-08/msg03353.html
Before this patch,the result will be changed if you change host's clock.
It makes use of the following codes in qemu-timer.c:
if (now < last) {
notifier_list_notify(&clock->reset_notifiers, &now);
}
It is useless if you register a QEMU_CLOCK_REALTIME's clock_reset_notifier,
---
hw/timer/mc146818rtc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
index df54546..821c27e 100644
--- a/hw/timer/mc146818rtc.c
+++ b/hw/timer/mc146818rtc.c
@@ -879,7 +879,7 @@ static void rtc_realizefn(DeviceState *dev, Error
**errp)
check_update_timer(s);
s->clock_reset_notifier.notify = rtc_notify_clock_reset;
-qemu_clock_register_reset_notifier(QEMU_CLOCK_REALTIME,
+qemu_clock_register_reset_notifier(rtc_clock,
&s->clock_reset_notifier);
s->suspend_notifier.notify = rtc_notify_suspend;
--
Re: [Qemu-devel] [PATCH]Fix a error in mc146818rtc.c
1)“ it's an automated output of perl simply changing one calling convention
to another”.What do you mean... I
can not find the point :)
2) The problem is :
a.use QEMU to run linux-0.2.img with command qemu-system-i386
linux-0.2.img or sth. like that
b.hwclock ,and we get a date1(2014-07-01 12:00,e.g.)
c.change the clock of host before date1(2014-04-01 12:00),called date2
d.hwclock,and we get another date3(2014-07-01,12:01)
e. before that patch date3 is synchronized with host,so it changed to
a time date3>date2 && date3date1
3)why we set a reset_notifiers of QEMU_CLOCK_REALTIME? Any comment to that?
A QEMU_CLOCK_REALTIME clock will
not call its reset_notifiers when the time is adjusted to a time-point
before.The reset_notifiers is useless for this type of QEMUClock.
2014-07-01 4:08 GMT+08:00 Alex Bligh :
>
>
> On 30 Jun 2014, at 20:53, Lb peace wrote:
>
> > If you use hwclock in guest os ,you will find the result of hwclock
> isn't changed after changing host os's clock.
> > I find this issue is generated in this patch:
>
> I find it hard to believe that the patch you mention is the problem,
> as it's an automated output of perl simply changing one calling
> convention to another.
>
> Is this because you are using an unusual clock= option?
>
> Alex
>
>
>
> > http://lists.gnu.org/archive/html/qemu-devel/2013-08/msg03353.html
> > Before this patch,the result will be changed if you change host's clock.
> > It makes use of the following codes in qemu-timer.c:
> > if (now < last) {
> > notifier_list_notify(&clock->reset_notifiers, &now);
> > }
> > It is useless if you register a QEMU_CLOCK_REALTIME's
> clock_reset_notifier,
> > ---
> > hw/timer/mc146818rtc.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
> > index df54546..821c27e 100644
> > --- a/hw/timer/mc146818rtc.c
> > +++ b/hw/timer/mc146818rtc.c
> > @@ -879,7 +879,7 @@ static void rtc_realizefn(DeviceState *dev, Error
> **errp)
> > check_update_timer(s);
> >
> > s->clock_reset_notifier.notify = rtc_notify_clock_reset;
> > -qemu_clock_register_reset_notifier(QEMU_CLOCK_REALTIME,
> > +qemu_clock_register_reset_notifier(rtc_clock,
> > &s->clock_reset_notifier);
> >
> > s->suspend_notifier.notify = rtc_notify_suspend;
> > --
> >
>
> --
> Alex Bligh
>
>
>
>
>
