Re: dropping 32-bit host support

[Andrew Randrianasulu]

чт, 16 мар. 2023 г., 15:35 Daniel P. Berrangé :

> On Thu, Mar 16, 2023 at 02:11:08PM +0300, Andrew Randrianasulu wrote:
> > чт, 16 мар. 2023 г., 14:02 Thomas Huth :
> >
> > > On 16/03/2023 11.22, Andrew Randrianasulu wrote:
> > > >
> > > >
> > > > чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu <
> randrianas...@gmail.com
> > > > <mailto:randrianas...@gmail.com>>:
> > > >
> > > >
> > > >
> > > > чт, 16 мар. 2023 г., 11:31 Thomas Huth  > > > <mailto:th...@redhat.com>>:
> > > >
> > > > On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> > > >  > On 16/3/23 08:17, Andrew Randrianasulu wrote:
> > > >  >>
> > > >  >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé
> > > > mailto:phi...@linaro.org>
> > > >  >> <mailto:phi...@linaro.org <mailto:phi...@linaro.org>>>:
> > > >  >>
> > > >  >> Hi Andrew,
> > > >  >>
> > > >  >> On 16/3/23 01:57, Andrew Randrianasulu wrote:
> > > >  >>  > Looking at https://wiki.qemu.org/ChangeLog/8.0
> > > > <https://wiki.qemu.org/ChangeLog/8.0>
> > > >  >> <https://wiki.qemu.org/ChangeLog/8.0
> > > > <https://wiki.qemu.org/ChangeLog/8.0>>
> > > >  >>  > <https://wiki.qemu.org/ChangeLog/8.0
> > > > <https://wiki.qemu.org/ChangeLog/8.0>
> > > >  >> <https://wiki.qemu.org/ChangeLog/8.0
> > > > <https://wiki.qemu.org/ChangeLog/8.0>>>
> > > >  >>  >
> > > >  >>  > ===
> > > >  >>  > System emulation on 32-bit x86 and ARM hosts has
> been
> > > > deprecated.
> > > >  >> The
> > > >  >>  > QEMU project no longer considers 32-bit x86 and
> ARM
> > > > support for
> > > >  >> system
> > > >  >>  > emulation to be an effective use of its limited
> > > > resources, and thus
> > > >  >>  > intends to discontinue.
> > > >  >>  >
> > > >  >>  >   ==
> > > >  >>  >
> > > >  >>  > well, I guess arguing from memory-consuption
> point on
> > > 32
> > > > bit x86
> > > >  >> hosts
> > > >  >>  > (like my machine where I run 32 bit userspace on
> 64
> > > bit
> > > > kernel)
> > > >
> > > > All current PCs have multiple gigabytes of RAM, so using a
> 32-bit
> > > > userspace
> > > > to save some few bytes sounds weird.
> > > >
> > > >
> > > > I think difference more like in 20-30% (on disk and in ram), not
> *few
> > > > bytes*.
> > > >
> > > >
> > > > I stand (self) corrected on *on disk* binary size, this parameter
> tend
> > > to be
> > > > ~same between bash / php binaries from Slackware 15.0 i586/x86_64. I
> do
> > > not
> > > > have full identical x64 Slackware setup for measuring memory impact.
> > > >
> > > >
> > > > Still, pushing users into endless hw upgrade is no fun:
> > > >
> > > >
> > >
> https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/
> > > >
> > > >
> > > > note e-waste and energy consumption
> > >
> > > Now you're mixing things quite badly. That would be an argument in the
> > > years
> > > before 2010 maybe, when not everybody had a 64-bit processor in their
> PC
> > > yet, but it's been now more than 12 years that all recent Desktop
> > > processors
> >
> > ===
> >
> >
> > Laptops, tablets etc exist.
> >
> >
> > >
> > > feature 64-bit mode. So if QEMU stops supporting 32-bit x86
> environments,
> > > this is not forcing you to buy a new hardware, since you're having a
> > > 64-bit
> > > hardw

Re: dropping 32-bit host support

[Andrew Randrianasulu]

чт, 16 мар. 2023 г., 18:21 Warner Losh :

>
>
> On Thu, Mar 16, 2023 at 7:33 AM Thomas Huth  wrote:
>
>> If you'd followed the QEMU project, you'd know that there are very
>> helpful
>> people around, from all kind of companies, Linaro guys who help with
>> reviewing and merging non-ARM patches, Red Hatters who help with BSD
>
> and Haiku patches, etc.
>>
>
> Without this help, bsd-user would be dead. As it is, it is struggling with
> its own
> resource issues, but the kind help I've received from the QEMU project has
> motivated me to keep going in upstreaming what our fork has, as well as
> working to make the code better.
>
> I'll only add that FreeBSD's efforts to improve its CI story was derailed
> for two
> years by people like this, so it makes me happy to see lines being drawn
> in this thread.
>

Yeah, this. Just it seems we are ended up on different sides of said line.
But this is ok.


They aren't unreasonable, and look to me to be in the best
> interest of the QEMU project. You can't make everybody happy all the time.
> And while it's good to try sometimes, other times it bogs down real
> efforts to
> make things better. This is one of those times.
>
> Warner
>

Re: dropping 32-bit host support

[Andrew Randrianasulu]

чт, 16 мар. 2023 г., 16:32 Thomas Huth :

> On 16/03/2023 14.01, Andrew Randrianasulu wrote:
> ...
> > Well, this language about "market" and "investment"  not just figures of
> the
> > speech, sadly? Because paid developers work on  areas they paid to
> develop,
> > by boss with big bucks.
>
> Sorry for getting more explicit now, but: Can you please stop making such
> aggressive assertions which are obviously wrong and where you apparently
> have no clue about about?
>

I usually read much more than I write, thank you very much.



> If you'd followed the QEMU project, you'd know that there are very helpful
> people around, from all kind of companies, Linaro guys who help with
> reviewing and merging non-ARM patches, Red Hatters who help with BSD and
> Haiku patches, etc.
>
> Anyway, if you're not happy with the way the project is evolving, then
> start
> contributing instead of grumbling.
>


Is there any point to contributing to project that happily will told you to
.go smoke in a corner?

>
>   Thomas
>
>

Re: dropping 32-bit host support

[Andrew Randrianasulu]

чт, 16 мар. 2023 г., 15:35 Daniel P. Berrangé :

> On Thu, Mar 16, 2023 at 02:11:08PM +0300, Andrew Randrianasulu wrote:
> > чт, 16 мар. 2023 г., 14:02 Thomas Huth :
> >
> > > On 16/03/2023 11.22, Andrew Randrianasulu wrote:
> > > >
> > > >
> > > > чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu <
> randrianas...@gmail.com
> > > > <mailto:randrianas...@gmail.com>>:
> > > >
> > > >
> > > >
> > > > чт, 16 мар. 2023 г., 11:31 Thomas Huth  > > > <mailto:th...@redhat.com>>:
> > > >
> > > > On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> > > >  > On 16/3/23 08:17, Andrew Randrianasulu wrote:
> > > >  >>
> > > >  >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé
> > > > mailto:phi...@linaro.org>
> > > >  >> <mailto:phi...@linaro.org <mailto:phi...@linaro.org>>>:
> > > >  >>
> > > >  >> Hi Andrew,
> > > >  >>
> > > >  >> On 16/3/23 01:57, Andrew Randrianasulu wrote:
> > > >  >>  > Looking at https://wiki.qemu.org/ChangeLog/8.0
> > > > <https://wiki.qemu.org/ChangeLog/8.0>
> > > >  >> <https://wiki.qemu.org/ChangeLog/8.0
> > > > <https://wiki.qemu.org/ChangeLog/8.0>>
> > > >  >>  > <https://wiki.qemu.org/ChangeLog/8.0
> > > > <https://wiki.qemu.org/ChangeLog/8.0>
> > > >  >> <https://wiki.qemu.org/ChangeLog/8.0
> > > > <https://wiki.qemu.org/ChangeLog/8.0>>>
> > > >  >>  >
> > > >  >>  > ===
> > > >  >>  > System emulation on 32-bit x86 and ARM hosts has
> been
> > > > deprecated.
> > > >  >> The
> > > >  >>  > QEMU project no longer considers 32-bit x86 and
> ARM
> > > > support for
> > > >  >> system
> > > >  >>  > emulation to be an effective use of its limited
> > > > resources, and thus
> > > >  >>  > intends to discontinue.
> > > >  >>  >
> > > >  >>  >   ==
> > > >  >>  >
> > > >  >>  > well, I guess arguing from memory-consuption
> point on
> > > 32
> > > > bit x86
> > > >  >> hosts
> > > >  >>  > (like my machine where I run 32 bit userspace on
> 64
> > > bit
> > > > kernel)
> > > >
> > > > All current PCs have multiple gigabytes of RAM, so using a
> 32-bit
> > > > userspace
> > > > to save some few bytes sounds weird.
> > > >
> > > >
> > > > I think difference more like in 20-30% (on disk and in ram), not
> *few
> > > > bytes*.
> > > >
> > > >
> > > > I stand (self) corrected on *on disk* binary size, this parameter
> tend
> > > to be
> > > > ~same between bash / php binaries from Slackware 15.0 i586/x86_64. I
> do
> > > not
> > > > have full identical x64 Slackware setup for measuring memory impact.
> > > >
> > > >
> > > > Still, pushing users into endless hw upgrade is no fun:
> > > >
> > > >
> > >
> https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/
> > > >
> > > >
> > > > note e-waste and energy consumption
> > >
> > > Now you're mixing things quite badly. That would be an argument in the
> > > years
> > > before 2010 maybe, when not everybody had a 64-bit processor in their
> PC
> > > yet, but it's been now more than 12 years that all recent Desktop
> > > processors
> >
> > ===
> >
> >
> > Laptops, tablets etc exist.
> >
> >
> > >
> > > feature 64-bit mode. So if QEMU stops supporting 32-bit x86
> environments,
> > > this is not forcing you to buy a new hardware, since you're having a
> > > 64-bit
> > > hardw

Re: dropping 32-bit host support

[Andrew Randrianasulu]

чт, 16 мар. 2023 г., 14:02 Thomas Huth :

> On 16/03/2023 11.22, Andrew Randrianasulu wrote:
> >
> >
> > чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu  > <mailto:randrianas...@gmail.com>>:
> >
> >
> >
> > чт, 16 мар. 2023 г., 11:31 Thomas Huth  > <mailto:th...@redhat.com>>:
> >
> > On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> >  > On 16/3/23 08:17, Andrew Randrianasulu wrote:
> >  >>
> >  >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé
> > mailto:phi...@linaro.org>
> >  >> <mailto:phi...@linaro.org <mailto:phi...@linaro.org>>>:
> >  >>
> >  >> Hi Andrew,
> >  >>
> >  >> On 16/3/23 01:57, Andrew Randrianasulu wrote:
> >  >>  > Looking at https://wiki.qemu.org/ChangeLog/8.0
> > <https://wiki.qemu.org/ChangeLog/8.0>
> >  >> <https://wiki.qemu.org/ChangeLog/8.0
> > <https://wiki.qemu.org/ChangeLog/8.0>>
> >  >>  > <https://wiki.qemu.org/ChangeLog/8.0
> > <https://wiki.qemu.org/ChangeLog/8.0>
> >  >> <https://wiki.qemu.org/ChangeLog/8.0
> > <https://wiki.qemu.org/ChangeLog/8.0>>>
> >  >>  >
> >  >>  > ===
> >  >>  > System emulation on 32-bit x86 and ARM hosts has been
> > deprecated.
> >  >> The
> >  >>  > QEMU project no longer considers 32-bit x86 and ARM
> > support for
> >  >> system
> >  >>  > emulation to be an effective use of its limited
> > resources, and thus
> >  >>  > intends to discontinue.
> >  >>  >
> >  >>  >   ==
> >  >>  >
> >  >>  > well, I guess arguing from memory-consuption point on
> 32
> > bit x86
> >  >> hosts
> >  >>  > (like my machine where I run 32 bit userspace on 64
> bit
> > kernel)
> >
> > All current PCs have multiple gigabytes of RAM, so using a 32-bit
> > userspace
> > to save some few bytes sounds weird.
> >
> >
> > I think difference more like in 20-30% (on disk and in ram), not *few
> > bytes*.
> >
> >
> > I stand (self) corrected on *on disk* binary size, this parameter tend
> to be
> > ~same between bash / php binaries from Slackware 15.0 i586/x86_64. I do
> not
> > have full identical x64 Slackware setup for measuring memory impact.
> >
> >
> > Still, pushing users into endless hw upgrade is no fun:
> >
> >
> https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/
> >
> >
> > note e-waste and energy consumption
>
> Now you're mixing things quite badly. That would be an argument in the
> years
> before 2010 maybe, when not everybody had a 64-bit processor in their PC
> yet, but it's been now more than 12 years that all recent Desktop
> processors

===


Laptops, tablets etc exist.


>
> feature 64-bit mode. So if QEMU stops supporting 32-bit x86 environments,
> this is not forcing you to buy a new hardware, since you're having a
> 64-bit
> hardware already anyway. If someone still has plain 32-bit x86 hardware
> around for their daily use, that's certainly not a piece of hardware you
> want to run QEMU on, since it's older than 12 years already, and thus not
> really strong enough to run a recent emulator in a recent way.
>

Well, current qemu runs quite well, than you very much (modulo all this
twiddling with command line switches). I think very fact it runs well (even
as tcg-only emulator, on integer tasks at least) on 32-bit hosts actually
good, and if 32-bit arm hardware can keep some codeways in working state
for me - even better.

But may be qemu as emulator and qemu as  industrial hypervisor actually
better to live separate lives? I do not know future, just dislike direction
winds are blowing  since long time, really.



>   Thomas
>
>

Re: dropping 32-bit host support

[Andrew Randrianasulu]

чт, 16 мар. 2023 г., 13:56 Philippe Mathieu-Daudé :

> On 16/3/23 11:22, Andrew Randrianasulu wrote:
> > чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu  > <mailto:randrianas...@gmail.com>>:
> > чт, 16 мар. 2023 г., 11:31 Thomas Huth  > <mailto:th...@redhat.com>>:
> > On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> >  > On 16/3/23 08:17, Andrew Randrianasulu wrote:
> >  >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé
> > mailto:phi...@linaro.org>
> >  >> <mailto:phi...@linaro.org <mailto:phi...@linaro.org>>>:
> >  >> On 16/3/23 01:57, Andrew Randrianasulu wrote:
> >  >>  > Looking at https://wiki.qemu.org/ChangeLog/8.0
> > <https://wiki.qemu.org/ChangeLog/8.0>
> >  >> <https://wiki.qemu.org/ChangeLog/8.0
> > <https://wiki.qemu.org/ChangeLog/8.0>>
> >  >>  > <https://wiki.qemu.org/ChangeLog/8.0
> > <https://wiki.qemu.org/ChangeLog/8.0>
> >  >> <https://wiki.qemu.org/ChangeLog/8.0
> > <https://wiki.qemu.org/ChangeLog/8.0>>>
> >  >>  >
> >  >>  > ===
> >  >>  > System emulation on 32-bit x86 and ARM hosts has been
> > deprecated.
> >  >> The
> >  >>  > QEMU project no longer considers 32-bit x86 and ARM
> > support for
> >  >> system
> >  >>  > emulation to be an effective use of its limited
> > resources, and thus
> >  >>  > intends to discontinue.
>
>
> > Still, pushing users into endless hw upgrade is no fun:
> >
> >
> https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/
> <
> https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/
> >
> >
> > note e-waste and energy consumption
> >
> > This graph does not make me happy:
> >
> >
> https://ourworldindata.org/grapher/global-energy-substitution?time=earliest..2021
> <
> https://ourworldindata.org/grapher/global-energy-substitution?time=earliest..2021
> >
> >
> > Note this paradox too
> >
> > https://en.m.wikipedia.org/wiki/Jevons_paradox
> > <https://en.m.wikipedia.org/wiki/Jevons_paradox>
>
>
> >  >> [...] I also ran qemu-system-ppc on Huawei Matepad T8 (32
> > bit Android,
> >  >> too) for emulating old mac os 9. Yes, I can wait 10 min per
> > guest boot.
> >  >> Fedora 36 armhf boots even slower on emulation!
> >
> > Yes, but for such scenarios, you can also use older versions of
> > QEMU, you
> > don't need the latest and greatest shiny QEMU version.
>
> Thomas answer still applies: if you can use QEMU v8.0.0 to emulate
> macOS 9 on your Huawei Matepad T8 with 32-bit Android, why worry
> about trying to use future QEMU versions?
>

Because Termux (only one currently supported distro for bare Android, as
far as I know, everything else either unsupported or run under it, with
some space penalty due to not using Android's libraries) will update qemu
As Fast As Possible, being rolling release.


Again, I as maintainer/developer (due to our real developer  being dead
from road  incident) of cinelerra-gg I only can recommend to try your
favourite projects in somewhat constrained environment, I tweaked our build
system quite heavily simply because I was forced by device's constrains.

Also, for CI thing may be lessen compiler optimization levels at least for
some runs? And/or tweak ccache compression 

>

Re: dropping 32-bit host support

[Andrew Randrianasulu]

чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu :

>
>
> чт, 16 мар. 2023 г., 11:31 Thomas Huth :
>
>> On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
>> > On 16/3/23 08:17, Andrew Randrianasulu wrote:
>> >>
>> >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé > >> <mailto:phi...@linaro.org>>:
>> >>
>> >> Hi Andrew,
>> >>
>> >> On 16/3/23 01:57, Andrew Randrianasulu wrote:
>> >>  > Looking at https://wiki.qemu.org/ChangeLog/8.0
>> >> <https://wiki.qemu.org/ChangeLog/8.0>
>> >>  > <https://wiki.qemu.org/ChangeLog/8.0
>> >> <https://wiki.qemu.org/ChangeLog/8.0>>
>> >>  >
>> >>  > ===
>> >>  > System emulation on 32-bit x86 and ARM hosts has been
>> deprecated.
>> >> The
>> >>  > QEMU project no longer considers 32-bit x86 and ARM support for
>> >> system
>> >>  > emulation to be an effective use of its limited resources, and
>> thus
>> >>  > intends to discontinue.
>> >>  >
>> >>  >   ==
>> >>  >
>> >>  > well, I guess arguing from memory-consuption point on 32 bit x86
>> >> hosts
>> >>  > (like my machine where I run 32 bit userspace on 64 bit kernel)
>>
>> All current PCs have multiple gigabytes of RAM, so using a 32-bit
>> userspace
>> to save some few bytes sounds weird.
>>
>
> I think difference more like in 20-30% (on disk and in ram), not *few
> bytes*.
>

I stand (self) corrected on *on disk* binary size, this parameter tend to
be ~same between bash / php binaries from Slackware 15.0 i586/x86_64. I do
not have full identical x64 Slackware setup for measuring memory impact.


Still, pushing users into endless hw upgrade is no fun:

https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/

note e-waste and energy consumption

This graph does not make me happy:

https://ourworldindata.org/grapher/global-energy-substitution?time=earliest..2021

Note this paradox too

https://en.m.wikipedia.org/wiki/Jevons_paradox

Yes, weirdly or not basically I talk about same thing as "we are running
out of CI  quota". But. With ~all developers following mindlessly into
"upgrade now, think later if at all" whole dependency tree will be heavier
and heavier.


I guess whole move to gitlab also was not from overly good life  I
wonder of those c:\ paths I saw while looking into build status  are real
and mean CI running on Windows? Or it was just some strange fake thing
. is Windows cheaper? Is it really better when it comes to containers?



Also, this whole "my program is only one running on user's machine"  is
> flawed.
>
>
>
>> (and in case you're talking about a very old PC that cannot be extened
>> anymore, you're likely better off with an older version of QEMU anyway)
>>
>> >>
>> >> If you use a 64-bit kernel, then your host is 64-bit :)
>> >>
>> >>
>> >>
>> >> No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all
>> 32bit.
>> >> So, qemu naturally will be 32-bit binary on my system.
>> >
>> > This configuration is still supported!
>> >
>> > Thomas, should we clarify yet again? Maybe adding examples?
>>
>> There are two aspects here:
>>
>> 1) 32-bit KVM support - this won't be supported in the future anymore.
>> Since
>> running a 32-bit QEMU on a 64-bit kernel still uses the 32-bit KVM API,
>> KVM
>> also won't be possible anymore with a QEMU that has been compiled in
>> 32-bit
>> mode.
>>
>> 2) Compiling a 32-bit QEMU binary won't be officially supported anymore.
>> We
>> won't waste any more precious CI minutes on this (which is where we're
>> struggling the most currently), and likely no active support for finding
>> and
>> fixing bugs.
>
>
> Well, does this CI thing reuse build objects (even indirectly, via ccache)
> currently?
>
>
> But I guess we won't actively disable this possibility
>> (especially since we did not deprecate the corresponding 32-bit
>> linux-user
>> emulation yet, so the emulation code will mostly still stay around).
>>
>> In the long run, we likely want to get rid of the separate compilation of
>> the qemu-system-i386 binary, too, but that's still to be discussed. E.g.
>> we
>> could add a speci

Re: dropping 32-bit host support

[Andrew Randrianasulu]

чт, 16 мар. 2023 г., 13:01 Markus Armbruster :

> Thomas Huth  writes:
>
> [...]
>
> > The problem is really that we don't have unlimited resources in the
> > QEMU project. Currently we're heavily struggling with the load in the
> > CI, but also pure man power is always very scarce. So at one point in
> > time, you have to decide to say good bye to some old and hardly used
> > features - at least to stop testing and actively supporting it. If you
> > want to continue testing and fixing bugs for such host systems, that's
> > fine, of course, but don't expect the QEMU developers to do that job
> > in the future.
>
> This.
>
> We're out of free lunch.  We're glad you enjoyed it while it lasted.
>
> If you want more lunch, you need to join the kitchen.  Here are a few
> things we need to keep a host or target supported:
>
> * Competent maintainer(s) to relieve the ones who have maintained this
>   for you so far
>
> * CI runners to conserve scarce CI minutes (or the money to buy more)
>
> * Trustworthy system administrator(s) to set them up and keep them
>   running.
>


* Four - different developer culture, like, a bit fewer commits to run CI
with ? :)



>

Re: dropping 32-bit host support

[Andrew Randrianasulu]

чт, 16 мар. 2023 г., 11:31 Thomas Huth :

> On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> > On 16/3/23 08:17, Andrew Randrianasulu wrote:
> >>
> >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé  >> <mailto:phi...@linaro.org>>:
> >>
> >> Hi Andrew,
> >>
> >> On 16/3/23 01:57, Andrew Randrianasulu wrote:
> >>  > Looking at https://wiki.qemu.org/ChangeLog/8.0
> >> <https://wiki.qemu.org/ChangeLog/8.0>
> >>  > <https://wiki.qemu.org/ChangeLog/8.0
> >> <https://wiki.qemu.org/ChangeLog/8.0>>
> >>  >
> >>  > ===
> >>  > System emulation on 32-bit x86 and ARM hosts has been deprecated.
> >> The
> >>  > QEMU project no longer considers 32-bit x86 and ARM support for
> >> system
> >>  > emulation to be an effective use of its limited resources, and
> thus
> >>  > intends to discontinue.
> >>  >
> >>  >   ==
> >>  >
> >>  > well, I guess arguing from memory-consuption point on 32 bit x86
> >> hosts
> >>  > (like my machine where I run 32 bit userspace on 64 bit kernel)
>
> All current PCs have multiple gigabytes of RAM, so using a 32-bit
> userspace
> to save some few bytes sounds weird.
>

I think difference more like in 20-30% (on disk and in ram), not *few
bytes*. Also, this whole "my program is only one running on user's
machine"  is flawed.



> (and in case you're talking about a very old PC that cannot be extened
> anymore, you're likely better off with an older version of QEMU anyway)
>
> >>
> >> If you use a 64-bit kernel, then your host is 64-bit :)
> >>
> >>
> >>
> >> No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all 32bit.
> >> So, qemu naturally will be 32-bit binary on my system.
> >
> > This configuration is still supported!
> >
> > Thomas, should we clarify yet again? Maybe adding examples?
>
> There are two aspects here:
>
> 1) 32-bit KVM support - this won't be supported in the future anymore.
> Since
> running a 32-bit QEMU on a 64-bit kernel still uses the 32-bit KVM API,
> KVM
> also won't be possible anymore with a QEMU that has been compiled in
> 32-bit
> mode.
>
> 2) Compiling a 32-bit QEMU binary won't be officially supported anymore.
> We
> won't waste any more precious CI minutes on this (which is where we're
> struggling the most currently), and likely no active support for finding
> and
> fixing bugs.


Well, does this CI thing reuse build objects (even indirectly, via ccache)
currently?


But I guess we won't actively disable this possibility
> (especially since we did not deprecate the corresponding 32-bit linux-user
> emulation yet, so the emulation code will mostly still stay around).
>
> In the long run, we likely want to get rid of the separate compilation of
> the qemu-system-i386 binary, too, but that's still to be discussed. E.g.
> we
> could add a special run mode to the qemu-system-x86_64 instead that makes
> sure that the guest can only run in 32-bit mode.
>
> >> host: hardware where you run QEMU
> >> guest: what is run within QEMU
> >>
> >> Running 32-bit *guest* on your 64-bit *host* is still supported.
>
> If the complete userspace is 32-bit, I'd rather consider it a 32-bit host.
>
> >> [...] I also ran qemu-system-ppc on Huawei Matepad T8 (32 bit Android,
> >> too) for emulating old mac os 9. Yes, I can wait 10 min per guest boot.
> >> Fedora 36 armhf boots even slower on emulation!
>
> Yes, but for such scenarios, you can also use older versions of QEMU, you
> don't need the latest and greatest shiny QEMU version.
>
> >> Well, sometimes simple patch restores functionality. I patched for
> example
> >> olive-editor to run on 32 bit, and before this intel embree (raytracing
> >> kernels for Lux renderer). So, _sometimes_ it really not that costly.
> >> While if this CI thing really runs per-commit and thrown away each
> result
> >> ... may be letting interested users to build things on their own
> machines
> >> (and share patches, if they develop them, publicly) actually good idea.
>
> The problem is really that we don't have unlimited resources in the QEMU
> project. Currently we're heavily struggling with the load in the CI, but
> also pure man power is always very scarce. So at one point in time, you
> have
> to decide to say good bye to some old and hardly used features - at least
> to
> stop testing and actively supporting it. If you want to continue testing
> and
> fixing bugs for such host systems, that's fine, of course, but don't
> expect
> the QEMU developers to do that job in the future.
>
>   Thomas
>
>

Re: dropping 32-bit host support

[Andrew Randrianasulu]

чт, 16 мар. 2023 г., 10:36 Philippe Mathieu-Daudé :

> On 16/3/23 08:17, Andrew Randrianasulu wrote:
> >
> >
> > чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé  > <mailto:phi...@linaro.org>>:
> >
> > Hi Andrew,
> >
> > On 16/3/23 01:57, Andrew Randrianasulu wrote:
> >  > Looking at https://wiki.qemu.org/ChangeLog/8.0
> > <https://wiki.qemu.org/ChangeLog/8.0>
> >  > <https://wiki.qemu.org/ChangeLog/8.0
> > <https://wiki.qemu.org/ChangeLog/8.0>>
> >  >
> >  > ===
> >  > System emulation on 32-bit x86 and ARM hosts has been deprecated.
> > The
> >  > QEMU project no longer considers 32-bit x86 and ARM support for
> > system
> >  > emulation to be an effective use of its limited resources, and
> thus
> >  > intends to discontinue.
> >  >
> >  >   ==
> >  >
> >  > well, I guess arguing from memory-consuption point on 32 bit x86
> > hosts
> >  > (like my machine where I run 32 bit userspace on 64 bit kernel)
> > is not
> >
> > If you use a 64-bit kernel, then your host is 64-bit :)
> >
> >
> >
> > No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all 32bit.
> > So, qemu naturally will be 32-bit binary on my system.
>
> This configuration is still supported!
>
> Thomas, should we clarify yet again? Maybe adding examples?
>
> > host: hardware where you run QEMU
> > guest: what is run within QEMU
> >
> > Running 32-bit *guest* on your 64-bit *host* is still supported.
> >
> > We don't plan to support running 32-bit WinXP x86 (guest) on 32-bit
> > Raspberry Pi 2 (host) for example.
> >
> >  > going anywhere, but what about 32bit userspace on Android tablets,
> >  > either via Limbo emulator or qemu itself in Termux?
> >
> > *System* emulation [on 32-bit hosts] is deprecated. User emulation
> > (such linux-user) is not. For example, you can still run 64-bit
> x86_64
> > Linux binaries on a 32-bit ARM Raspberry Pi.
> >
> >
> >
> > Well, unrooted Android does not allow you to just load some perfectly
> > fine kernel module, so user-space emulation can't do all things
> > system-level one can. I also ran qemu-system-ppc on Huawei Matepad T8
> > (32 bit Android, too) for emulating old mac os 9. Yes, I can wait 10 min
> > per guest boot. Fedora 36 armhf boots even slower on emulation!
>
> Huawei MatePad T8 is based on a MediaTek MT8768 CPU which contains
> ARM Cortex-A53 cores. These cores implements the ARMv8-A 64-bit ISA,
> so theoretically it is able to run a 64-bit Android.
>

Good luck installing non-vendor Android on off the shelf device, also good
luck running 64bit Android in 2gb ram. To be honest yes before I had only
Android + termux setup for all my computer needs I cared less about
upstream removals - because I usually can revert things locally on
Slackware. But Termux is rolling distro, and there is not many
alternatives. So upstream decisions will hit here fast and hard.


> >  > At least I hope it will be not *actively* (intentionally) broken,
> > just
> >  > ...unsupported (so users who know how to run git revert still
> > will get
> >  > their build for some more time).
> >
> > Unsupported code almost always unintentionally end bit-rotting...
> >
> >
> >
> > Well, sometimes simple patch restores functionality. I patched for
> > example olive-editor to run on 32 bit, and before this intel embree
> > (raytracing kernels for Lux renderer). So, _sometimes_ it really not
> > that costly. While if this CI thing really runs per-commit and thrown
> > away each result ... may be letting interested users to build things on
> > their own machines (and share patches, if they develop them, publicly)
> > actually good idea.
> >
> >
> >
> > I hope this is clearer.
> >
> > Regards,
> >
> > Phil.
> >
>
>

Re: dropping 32-bit host support

[Andrew Randrianasulu]

чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé :

> Hi Andrew,
>
> On 16/3/23 01:57, Andrew Randrianasulu wrote:
> > Looking at https://wiki.qemu.org/ChangeLog/8.0
> > <https://wiki.qemu.org/ChangeLog/8.0>
> >
> > ===
> > System emulation on 32-bit x86 and ARM hosts has been deprecated. The
> > QEMU project no longer considers 32-bit x86 and ARM support for system
> > emulation to be an effective use of its limited resources, and thus
> > intends to discontinue.
> >
> >   ==
> >
> > well, I guess arguing from memory-consuption point on 32 bit x86 hosts
> > (like my machine where I run 32 bit userspace on 64 bit kernel) is not
>
> If you use a 64-bit kernel, then your host is 64-bit :)
>


No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all 32bit. So,
qemu naturally will be 32-bit binary on my system.



> host: hardware where you run QEMU
> guest: what is run within QEMU
>
> Running 32-bit *guest* on your 64-bit *host* is still supported.
>
> We don't plan to support running 32-bit WinXP x86 (guest) on 32-bit
> Raspberry Pi 2 (host) for example.
>
> > going anywhere, but what about 32bit userspace on Android tablets,
> > either via Limbo emulator or qemu itself in Termux?
>
> *System* emulation [on 32-bit hosts] is deprecated. User emulation
> (such linux-user) is not. For example, you can still run 64-bit x86_64
> Linux binaries on a 32-bit ARM Raspberry Pi.
>


Well, unrooted Android does not allow you to just load some perfectly fine
kernel module, so user-space emulation can't do all things system-level one
can. I also ran qemu-system-ppc on Huawei Matepad T8 (32 bit Android, too)
for emulating old mac os 9. Yes, I can wait 10 min per guest boot. Fedora
36 armhf boots even slower on emulation!


> > At least I hope it will be not *actively* (intentionally) broken, just
> > ...unsupported (so users who know how to run git revert still will get
> > their build for some more time).
>
> Unsupported code almost always unintentionally end bit-rotting...
>


Well, sometimes simple patch restores functionality. I patched for example
olive-editor to run on 32 bit, and before this intel embree (raytracing
kernels for Lux renderer). So, _sometimes_ it really not that costly. While
if this CI thing really runs per-commit and thrown away each result ... may
be letting interested users to build things on their own machines (and
share patches, if they develop them, publicly)  actually good idea.



> I hope this is clearer.
>
> Regards,
>
> Phil.
>

vgabios with voodoo3 suppirt for Bochs

[Andrew Randrianasulu]

Hello and sorry for possible interruption.

I was browsing various projects and found Bochs 2.7 was released on August,
1 2021 [0] together with vgabios 0.8a

http://www.nongnu.org/vgabios/

"2021-06-03 vruppert Version 0.8a of the LGPL'd VGABios with Voodoo Banshee
for Bochs and Cirrus support for Bochs and Qemu is available now. This
version will be included in the next Bochs release."

not really usable in qemu directly (at least voodoo3 part?) but might be
interesting for someone looking into gpu suppirt in qemu - supported or
future vga cards...

[0] https://svn.code.sf.net/p/bochs/code/tags/REL_2_7_FINAL/bochs/CHANGES

Re: X on old (non-x86) Linux guests

[Andrew Randrianasulu]

On Wednesday, April 28, 2021, BALATON Zoltan  wrote:

> On Wed, 28 Apr 2021, Andrew Randrianasulu wrote:
>
>> On Wednesday, April 28, 2021, Andrew Randrianasulu <
>> randrianas...@gmail.com>
>> wrote:
>>
>>> On Monday, April 26, 2021, BALATON Zoltan  wrote:
>>>
>>>> On Mon, 26 Apr 2021, Dr. David Alan Gilbert wrote:
>>>>
>>>>>  Over the weekend I got a Red Hat 6.x (not RHEL!) for Alpha booting
>>>>> under QEMU which was pretty neat.  But I failed to find a succesful
>>>>> combination to get X working; has anyone any suggestions?
>>>>>
>>>>>
>>>> Adding Andrew who has experimented with old X framebuffer so he may
>>>> remember something more but that was on x86.
>>>>
>>>
>>>
>>>
>>> Sorry, I still away from my desktop (with notes/logs), not sure when
>>> return..
>>> I do not think I tried something that old.. Kernel 2.2 i guess, before
>>> any
>>> attempt at r128 drm Kernel module was written (in 2.4?) and so before ddx
>>> attempted to use that (as it tries by default in much newer distros)
>>>
>>
> Maybe it would work better with newer RedHat than 6.0? I think I've seen
> images up to at least 7.1 that supported alpha but I don't know how to boot
> them. I could get kernel and installer running with -kernel -initrd but did
> not find the CD on the defailt CMD646 controller (seems to only have driver
> for one SCSI controller) so I'm not sure how to try this. Trying to just
> boot from the CD without -kernel -initrd it just stops after displaying
> "Hello" in top left but that could be something about alpha firmware I
> don't know how to use.


I think alpha firmware is incomplete, not like real Alpha firmware..

I found you can try to install rh 7.1 on alpha from Hard drive or network
(ftp/http)

https://web.archive.org/web/20011120235248/http://www.redhat.com/docs/manuals/linux/RHL-7.1-Manual/alpha-install-guide/s1-guimode-sel-method.html

But this requires network boot disk... Not sure from where you can get
it...

>
> Regards,
> BALATON Zoltan
>

Re: X on old (non-x86) Linux guests

[Andrew Randrianasulu]

On Wednesday, April 28, 2021, Andrew Randrianasulu 
wrote:

>
>
> On Monday, April 26, 2021, BALATON Zoltan  wrote:
>
>> Hello,
>>
>> On Mon, 26 Apr 2021, Dr. David Alan Gilbert wrote:
>>
>>>  Over the weekend I got a Red Hat 6.x (not RHEL!) for Alpha booting
>>> under QEMU which was pretty neat.  But I failed to find a succesful
>>> combination to get X working; has anyone any suggestions?
>>>
>>
>> Adding Andrew who has experimented with old X framebuffer so he may
>> remember something more but that was on x86.
>
>
>
> Sorry, I still away from my desktop (with notes/logs), not sure when
> return..
> I do not think I tried something that old.. Kernel 2.2 i guess, before any
> attempt at r128 drm Kernel module was written (in 2.4?) and so before ddx
> attempted to use that (as it tries by default in much newer distros)
>
> I tried Last debian for alpha, (5.0.x?) on qemu, it had bugs in cirrusfb
> in 2.6.26 Kernel so i compiled like 2.6.32.last inside emulated system..
> This made fb works, But still there was no X for me... (can't recall exact
> error - May be even sigabort or sigbus - but do not count on my memory on
> this... /)
>
> Notes i used for launching qemu -
> https://virtuallyfun.com/wordpress/2014/02/19/alpha-linux-on-qemu/
> But Sadly pre-compressed disk image from that post really gone (it uses
> funny error Page telling you to use login/password, yet file can't be
> downloaded...)
>


Upd:
https://web.archive.org/web/20191021110430/https://vpsland.superglobalmegacorp.com/old/install/linux/DecAlpha/alpha-linux.7z

This May give you kernel/initrd/disk image..

>
>
>>  That distro was from around 2000; the challenge is since we don't have
>>> VESA on non-x86, we can't change mode that way, so generic XF86_SVGA
>>> doesn't want to play with any of the devices.
>>>
>>>  I also tried the ati device, but the accelerated mach64 driver
>>> didn't recognise that ID.
>>>
>>
>> The ati-vga partially emulates an ATI Rage128 Pro so it won't work with
>> mach64 driver that is older and while functionally similar has different
>> registers. You probably need to load aty128fb and then set a mode with
>> fbset then may need to edit X conf but I forgot which option was neded,
>> something about UseFb or similar so it won't try to change mode itself but
>> use the already set Linux FB because otherwise it did not detect the card
>> properly but I don'r remember the details so may be wrong. Also some 2D
>> accel is emulated so may work without disabling it but I think has some
>> bugs so it may have glitches.
>>
>>  Has anyone found any combo that works?
>>> I suspect using one of the existing devices, lying about PCI ID, and
>>> then turning off all accelerations might have a chance but I've not got
>>> that far.
>>>
>>
>> Changing the PCI ID may not help as these ATI chips have different
>> registers so only compatible with the right drivers. I've tried to use
>> current ati-vga with a Mac ROM that expects mach64 but it did not work.
>>
>> It may help to add -trace enable="ati*" and maybe also enable some debug
>> defines in ati_int.h to see if it accesses the card at all but with the
>> right driver that works with Rage128Pro it should produce some picture at
>> least in fb console and we could run X with it on x86 before.
>>
>> More info on ati-vga is here: https://osdn.net/projects/qmig
>> a/wiki/SubprojectAti
>>
>> By the way, last time I've experimented with it I've found that mouse
>> pointer getting out of sync and jumping around is probably a result of
>> mouse acceleration on the host is not taken into account when tracking
>> guest pointer position. Is that possible and is there a way to fix it?
>>
>> Regards,
>> BALATON Zoltan
>>
>

Re: X on old (non-x86) Linux guests

[Andrew Randrianasulu]

On Monday, April 26, 2021, BALATON Zoltan  wrote:

> Hello,
>
> On Mon, 26 Apr 2021, Dr. David Alan Gilbert wrote:
>
>>  Over the weekend I got a Red Hat 6.x (not RHEL!) for Alpha booting
>> under QEMU which was pretty neat.  But I failed to find a succesful
>> combination to get X working; has anyone any suggestions?
>>
>
> Adding Andrew who has experimented with old X framebuffer so he may
> remember something more but that was on x86.



Sorry, I still away from my desktop (with notes/logs), not sure when
return..
I do not think I tried something that old.. Kernel 2.2 i guess, before any
attempt at r128 drm Kernel module was written (in 2.4?) and so before ddx
attempted to use that (as it tries by default in much newer distros)

I tried Last debian for alpha, (5.0.x?) on qemu, it had bugs in cirrusfb in
2.6.26 Kernel so i compiled like 2.6.32.last inside emulated system.. This
made fb works, But still there was no X for me... (can't recall exact error
- May be even sigabort or sigbus - but do not count on my memory on this...
/)

Notes i used for launching qemu -
https://virtuallyfun.com/wordpress/2014/02/19/alpha-linux-on-qemu/
But Sadly pre-compressed disk image from that post really gone (it uses
funny error Page telling you to use login/password, yet file can't be
downloaded...)


>  That distro was from around 2000; the challenge is since we don't have
>> VESA on non-x86, we can't change mode that way, so generic XF86_SVGA
>> doesn't want to play with any of the devices.
>>
>>  I also tried the ati device, but the accelerated mach64 driver
>> didn't recognise that ID.
>>
>
> The ati-vga partially emulates an ATI Rage128 Pro so it won't work with
> mach64 driver that is older and while functionally similar has different
> registers. You probably need to load aty128fb and then set a mode with
> fbset then may need to edit X conf but I forgot which option was neded,
> something about UseFb or similar so it won't try to change mode itself but
> use the already set Linux FB because otherwise it did not detect the card
> properly but I don'r remember the details so may be wrong. Also some 2D
> accel is emulated so may work without disabling it but I think has some
> bugs so it may have glitches.
>
>  Has anyone found any combo that works?
>> I suspect using one of the existing devices, lying about PCI ID, and
>> then turning off all accelerations might have a chance but I've not got
>> that far.
>>
>
> Changing the PCI ID may not help as these ATI chips have different
> registers so only compatible with the right drivers. I've tried to use
> current ati-vga with a Mac ROM that expects mach64 but it did not work.
>
> It may help to add -trace enable="ati*" and maybe also enable some debug
> defines in ati_int.h to see if it accesses the card at all but with the
> right driver that works with Rage128Pro it should produce some picture at
> least in fb console and we could run X with it on x86 before.
>
> More info on ati-vga is here: https://osdn.net/projects/qmig
> a/wiki/SubprojectAti
>
> By the way, last time I've experimented with it I've found that mouse
> pointer getting out of sync and jumping around is probably a result of
> mouse acceleration on the host is not taken into account when tracking
> guest pointer position. Is that possible and is there a way to fix it?
>
> Regards,
> BALATON Zoltan
>

[Bug 1847525] Re: qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on

[Andrew Randrianasulu]

this one still with me.

qemu-system-x86_64 --version
QEMU emulator version 4.2.91 (v5.0.0-rc1-dirty)

on 32-bit host (Slackware, but with 64-bit kernel) compiled with gcc
5.5.0

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1847525

Title:
  qemu-system-i386 eats a lot of cpu after just few hours,  with
  sdl,gl=on

Status in QEMU:
  New

Bug description:
  I already send this email to qemu-disc...@nongnu.org , but I can't see
  it arriving in archives, so here  is copy.

  Hello, all!

  I use qemu-system-i386/qemu-system_x86_64 for rebuilding Slax-like live 
cd/dvd.
  Usually guests (with various self-compiled kernels and X stack with kde3 on 
top of them)
  boot up normally, but if I left them to run in GUI mode for few hours - qemu 
process on host
  started to eat more and more cpu for itself - more notiecable if I set host 
cpu to lowest possible
  frequency via trayfreq applet (1400Mhz in my case).

  Boot line a bit complicated, but I really prefer to have sound and usb inside 
VM.
  qemu-system-i386 -cdrom /dev/shm/CDROM-4.4.194_5.iso -m 1.9G -enable-kvm 
-soundhw es1370 -smp 2 -display sdl,gl=on -usb -cpu host -rtc clock=vm

  rtc clock=vm was taken from https://bugs.launchpad.net/qemu/+bug/1174654 but 
apparently not helping.
  After just 3 hours of uptime (copied line from 'top' on host)

  31943 guest 20   0 2412m 791m  38m R   51  6.7  66:36.51 qemu-
  system-i38

  I use Xorg 1.19.7 on host, with mesa git/nouveau as GL driver. But my card 
has not very big amount of VRAM - only 384Mb.
  May be this limitation is playing some role .. but 'end-user' result was 
after 1-2 day of guest uptime I run into completely frozen guest 
  (may be when qemu was hitting 100 one core usage on host some internal timer 
just made guest kernel too upset/froze?
   I was sleeping or doing other things on host  for all this time, with VM 
just supposedly running at another virtual desktop - 
  in KDE3 + built-in compositor )

  I wonder if more mainstream desktop users (on GNOME, Xfce, etc) and/or users 
of other distros (I use self-re-compiled Slackware)
  actually can see same problem?

  qemu-system-i386 --version
  QEMU emulator version 4.1.50 (v4.1.0-1188-gc6f5012ba5-dirty)
  but I saw same behavior for quite some time .. just never reported it in hope 
it will go away.

  cat /proc/cpuinfo
  processor   : 0
  vendor_id   : AuthenticAMD
  cpu family  : 21
  model   : 2
  model name  : AMD FX(tm)-4300 Quad-Core Processor
  stepping: 0
  microcode   : 0x6000852
  cpu MHz : 1399.977
  cache size  : 2048 KB
  physical id : 0
  siblings: 4
  core id : 0
  cpu cores   : 2
  apicid  : 16
  initial apicid  : 0
  fpu : yes
  fpu_exception   : yes
  cpuid level : 13
  wp  : yes
  flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf 
pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c 
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch 
osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core 
perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save 
tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
  bugs: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 
spec_store_bypass
  bogomips: 7600.06
  TLB size: 1536 4K pages
  clflush size: 64
  cache_alignment : 64
  address sizes   : 48 bits physical, 48 bits virtual
  power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

  [and 3x more of the same, for 3 remaining cores]

  Gcc is Slackware 14.2's gcc 5.5.0, but I saw this with 4.9.2 too.
  This might be 32-bit host problem. But may be just no-one tried to run qemu 
with GUI guest for literaly days?

  Host kernel is
   uname -a
  Linux slax 5.1.12-x64 #1 SMP PREEMPT Wed Jun 19 12:31:05 MSK 2019 x86_64 AMD 
FX(tm)-4300 Quad-Core Processor AuthenticAMD GNU/Linux

  I was trying newish 5.3.2 but my compilation was not as stable as this one 
  (I tend to change few things, like max cpu count, preemption mode, numa 
support  
  for more distribution-like, yet most stable  and performant for me kernel)

  Kernel world is moving fast, so I'll try to recompile new 5.3.x too
  

  
  I guess I  should provide perf/profiler output, but for  this I need to 
recompile qemu. 
  I'll try to come back with more details soon.

  Thanks for your attention and possible feedback!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1847525/+subscriptions

[Bug 1837049] Re: qemu-system-ppc segfaults with -display sdl

[Andrew Randrianasulu]

I think this one is fixed, I can boot Lubuntu to desktop like this:

qemu-system-ppc -cdrom /dev/shm/lubuntu-16.04-desktop-powerpc.iso -boot
d -display sdl,gl=on -g 1024x768x32 -M mac99,via=pmu -cpu G4 -device
ES1370 -m 2047 -accel tcg,tb-size=384 -device usb-mouse

without any crash, tried few times.

Note, tb-size seems to be important on 32-bit host now, near qemu 5.0.

qemu-system-ppc --version
QEMU emulator version 4.2.91 (v5.0.0-rc1-dirty)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

-dirty probably because I reinstalled SDL2 (2.0.9- > 2.0.12 during
compilation of qemu). I also have different glibc this time (2.30
instead of 2.23)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1837049

Title:
  qemu-system-ppc segfaults with -display sdl

Status in QEMU:
  New

Bug description:
  Hello.

  I was trying to debug this segfault:
  https://lists.nongnu.org/archive/html/qemu-ppc/2019-07/msg00186.html

  I recompiled latest qemu from git (commit 
0b18cfb8f1828c905139b54c8644b0d8f4aad879 ), using this configure line:
  ./configure --target-list=i386-softmmu,x86_64-softmmu,ppc-softmmu 
--audio-drv-list=alsa --disable-werror --extra-cflags="-Og" --enable-debug-tcg

  after this I tried original line under gdb, it was still segfaulting:

  --copy-
  gdb ./ppc-softmmu/qemu-system-ppc
  GNU gdb (GDB) 7.11.1
  Copyright (C) 2016 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "i586-slackware-linux".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .
  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ./ppc-softmmu/qemu-system-ppc...done.
  warning: File "/dev/shm/qemu/.gdbinit" auto-loading has been declined by your 
`auto-load safe-path' set to "$debugdir:$datadir/auto-load".
  To enable execution of this file add
  add-auto-load-safe-path /dev/shm/qemu/.gdbinit
  line to your configuration file "/home/guest/.gdbinit".
  To completely disable this security protection add
  set auto-load safe-path /
  line to your configuration file "/home/guest/.gdbinit".
  For more information about this security protection see the
  "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
  info "(gdb)Auto-loading safe path"
  (gdb) run  -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom 
/mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl,gl=on 
-vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370
  Starting program: /dev/shm/qemu/ppc-softmmu/qemu-system-ppc -M mac99,via=pmu 
-L ../queue-vga/pc-bios -cdrom 
/mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl,gl=on 
-vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/libthread_db.so.1".
  [New Thread 0xf560cb40 (LWP 8100)]
  [New Thread 0xf4c1ab40 (LWP 8101)]
  [New Thread 0xec1b7b40 (LWP 8102)]
  [New Thread 0xc5821b40 (LWP 8104)]
  [Thread 0xf4c1ab40 (LWP 8101) exited]
  [New Thread 0xf4c1ab40 (LWP 8119)]

  Thread 4 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0xec1b7b40 (LWP 8102)]
  0xf26c2e44 in code_gen_buffer ()
  (gdb) bt full
  #0  0x in code_gen_buffer ()
  #1  0x56710cf6 in cpu_exec (itb=, cpu=) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:173
  env = 
  ret = 
  last_tb = 
  tb_exit = 
  tb_ptr = 0xf26c2cc0  "‹]ш…Ы\017ЊБ\020"
  ret = 0
  insns_left = 
  cflags = 
  tb = 0x5722fe58
  last_tb = 
  tb_exit = 
  cc = 
  __func__ = "cpu_exec"
  ret = 
  sc = 
  #2  0x56710cf6 in cpu_exec (tb_exit=, last_tb=, tb=, cpu=) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:621
  ret = 0
  insns_left = 
  cflags = 
  tb = 0x5722fe58
  last_tb = 
  tb_exit = 
  cc = 
  __func__ = "cpu_exec"
  ret = 
  sc = 
  #3  0x56710cf6 in cpu_exec (cpu=0x573db8f8) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:732
  cflags = 
  tb = 0x5722fe58
  last_tb = 
  tb_exit = 
  cc = 
  __func__ = "cpu_exec"
  ret = 
  sc = 
  #4  0x566cfade in tcg_cpu_exec (cpu=0x573db8f8) at /dev/shm/qemu/cpus.c:1435
   

Re: [PATCH v4] Implement the Screamer sound chip for the mac99 machine type

[Andrew Randrianasulu]

Just thought I must share my uneducated guess on issue reported at

https://www.emaculation.com/forum/viewtopic.php?f=34&t=9820
> Please note that running with 1024Mb of memory will make sound stop working 
> in Mac OS 9.x. So run with less memory.
> As will running without virtual memory.

My guess this has something to do with device memory regions, may be because 
Linux  always uses Virtual memory
(MMU, address translation), as well as Mac OS X 10.x - this little issue was 
unnoticed until recently ?

Re: [RFC 0/8] ATI R300 emulated graphics card

[Andrew Randrianasulu]

Hello, Aaron!

While I can't help with coding (or even answering questions!)
I recall mr. Zoltan worked on emulating earlier ATI cards (r128/rv100)
and pointed me at this project:

https://github.com/xenia-project/xenia/tree/master/src/xenia/gpu
this basically about xbox 360, but GPU inside it supposed to be R500 alike.

[Bug 1847525] [NEW] qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on

[Andrew Randrianasulu]

Public bug reported:

I already send this email to qemu-disc...@nongnu.org , but I can't see
it arriving in archives, so here  is copy.

Hello, all!

I use qemu-system-i386/qemu-system_x86_64 for rebuilding Slax-like live cd/dvd.
Usually guests (with various self-compiled kernels and X stack with kde3 on top 
of them)
boot up normally, but if I left them to run in GUI mode for few hours - qemu 
process on host
started to eat more and more cpu for itself - more notiecable if I set host cpu 
to lowest possible
frequency via trayfreq applet (1400Mhz in my case).

Boot line a bit complicated, but I really prefer to have sound and usb inside 
VM.
qemu-system-i386 -cdrom /dev/shm/CDROM-4.4.194_5.iso -m 1.9G -enable-kvm 
-soundhw es1370 -smp 2 -display sdl,gl=on -usb -cpu host -rtc clock=vm

rtc clock=vm was taken from https://bugs.launchpad.net/qemu/+bug/1174654 but 
apparently not helping.
After just 3 hours of uptime (copied line from 'top' on host)

31943 guest 20   0 2412m 791m  38m R   51  6.7  66:36.51 qemu-
system-i38

I use Xorg 1.19.7 on host, with mesa git/nouveau as GL driver. But my card has 
not very big amount of VRAM - only 384Mb.
May be this limitation is playing some role .. but 'end-user' result was after 
1-2 day of guest uptime I run into completely frozen guest 
(may be when qemu was hitting 100 one core usage on host some internal timer 
just made guest kernel too upset/froze?
 I was sleeping or doing other things on host  for all this time, with VM just 
supposedly running at another virtual desktop - 
in KDE3 + built-in compositor )

I wonder if more mainstream desktop users (on GNOME, Xfce, etc) and/or users of 
other distros (I use self-re-compiled Slackware)
actually can see same problem?

qemu-system-i386 --version
QEMU emulator version 4.1.50 (v4.1.0-1188-gc6f5012ba5-dirty)
but I saw same behavior for quite some time .. just never reported it in hope 
it will go away.

cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 21
model   : 2
model name  : AMD FX(tm)-4300 Quad-Core Processor
stepping: 0
microcode   : 0x6000852
cpu MHz : 1399.977
cache size  : 2048 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 16
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf 
pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c 
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch 
osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core 
perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save 
tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bugs: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 
spec_store_bypass
bogomips: 7600.06
TLB size: 1536 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

[and 3x more of the same, for 3 remaining cores]

Gcc is Slackware 14.2's gcc 5.5.0, but I saw this with 4.9.2 too.
This might be 32-bit host problem. But may be just no-one tried to run qemu 
with GUI guest for literaly days?

Host kernel is
 uname -a
Linux slax 5.1.12-x64 #1 SMP PREEMPT Wed Jun 19 12:31:05 MSK 2019 x86_64 AMD 
FX(tm)-4300 Quad-Core Processor AuthenticAMD GNU/Linux

I was trying newish 5.3.2 but my compilation was not as stable as this one 
(I tend to change few things, like max cpu count, preemption mode, numa support 
 
for more distribution-like, yet most stable  and performant for me kernel)

Kernel world is moving fast, so I'll try to recompile new 5.3.x too 


I guess I  should provide perf/profiler output, but for  this I need to 
recompile qemu. 
I'll try to come back with more details soon.

Thanks for your attention and possible feedback!

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1847525

Title:
  qemu-system-i386 eats a lot of cpu after just few hours,  with
  sdl,gl=on

Status in QEMU:
  New

Bug description:
  I already send this email to qemu-disc...@nongnu.org , but I can't see
  it arriving in archives, so here  is copy.

  Hello, all!

  I use qemu-system-i386/qemu-system_x86_64 for rebuilding Slax-like live 
cd/dvd.
  Usually guests (with various self-compiled kernels and X stack with kde3 on 
top of them)
  boot up normally, but if I left them to run in GUI mode for few hours - qemu 
process on host
  started to eat more and mo

[Bug 1847525] Re: qemu-system-i386 eats a lot of cpu after just few hours, with sdl, gl=on

[Andrew Randrianasulu]

Illustration for this bug (link  to screenshot):

https://www.imgbin.net/z/9W9eVVvbll.png

as you hopefully can see, just after less than 6 hrs of guest uptime
HOST cpu is eaten at 70% by qemu-system-i386 task .. up from just 50%
two hours ago! By this rate it will not survive even day of uptime

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1847525

Title:
  qemu-system-i386 eats a lot of cpu after just few hours,  with
  sdl,gl=on

Status in QEMU:
  New

Bug description:
  I already send this email to qemu-disc...@nongnu.org , but I can't see
  it arriving in archives, so here  is copy.

  Hello, all!

  I use qemu-system-i386/qemu-system_x86_64 for rebuilding Slax-like live 
cd/dvd.
  Usually guests (with various self-compiled kernels and X stack with kde3 on 
top of them)
  boot up normally, but if I left them to run in GUI mode for few hours - qemu 
process on host
  started to eat more and more cpu for itself - more notiecable if I set host 
cpu to lowest possible
  frequency via trayfreq applet (1400Mhz in my case).

  Boot line a bit complicated, but I really prefer to have sound and usb inside 
VM.
  qemu-system-i386 -cdrom /dev/shm/CDROM-4.4.194_5.iso -m 1.9G -enable-kvm 
-soundhw es1370 -smp 2 -display sdl,gl=on -usb -cpu host -rtc clock=vm

  rtc clock=vm was taken from https://bugs.launchpad.net/qemu/+bug/1174654 but 
apparently not helping.
  After just 3 hours of uptime (copied line from 'top' on host)

  31943 guest 20   0 2412m 791m  38m R   51  6.7  66:36.51 qemu-
  system-i38

  I use Xorg 1.19.7 on host, with mesa git/nouveau as GL driver. But my card 
has not very big amount of VRAM - only 384Mb.
  May be this limitation is playing some role .. but 'end-user' result was 
after 1-2 day of guest uptime I run into completely frozen guest 
  (may be when qemu was hitting 100 one core usage on host some internal timer 
just made guest kernel too upset/froze?
   I was sleeping or doing other things on host  for all this time, with VM 
just supposedly running at another virtual desktop - 
  in KDE3 + built-in compositor )

  I wonder if more mainstream desktop users (on GNOME, Xfce, etc) and/or users 
of other distros (I use self-re-compiled Slackware)
  actually can see same problem?

  qemu-system-i386 --version
  QEMU emulator version 4.1.50 (v4.1.0-1188-gc6f5012ba5-dirty)
  but I saw same behavior for quite some time .. just never reported it in hope 
it will go away.

  cat /proc/cpuinfo
  processor   : 0
  vendor_id   : AuthenticAMD
  cpu family  : 21
  model   : 2
  model name  : AMD FX(tm)-4300 Quad-Core Processor
  stepping: 0
  microcode   : 0x6000852
  cpu MHz : 1399.977
  cache size  : 2048 KB
  physical id : 0
  siblings: 4
  core id : 0
  cpu cores   : 2
  apicid  : 16
  initial apicid  : 0
  fpu : yes
  fpu_exception   : yes
  cpuid level : 13
  wp  : yes
  flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf 
pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c 
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch 
osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core 
perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save 
tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
  bugs: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 
spec_store_bypass
  bogomips: 7600.06
  TLB size: 1536 4K pages
  clflush size: 64
  cache_alignment : 64
  address sizes   : 48 bits physical, 48 bits virtual
  power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

  [and 3x more of the same, for 3 remaining cores]

  Gcc is Slackware 14.2's gcc 5.5.0, but I saw this with 4.9.2 too.
  This might be 32-bit host problem. But may be just no-one tried to run qemu 
with GUI guest for literaly days?

  Host kernel is
   uname -a
  Linux slax 5.1.12-x64 #1 SMP PREEMPT Wed Jun 19 12:31:05 MSK 2019 x86_64 AMD 
FX(tm)-4300 Quad-Core Processor AuthenticAMD GNU/Linux

  I was trying newish 5.3.2 but my compilation was not as stable as this one 
  (I tend to change few things, like max cpu count, preemption mode, numa 
support  
  for more distribution-like, yet most stable  and performant for me kernel)

  Kernel world is moving fast, so I'll try to recompile new 5.3.x too
  

  
  I guess I  should provide perf/profiler output, but for  this I need to 
recompile qemu. 
  I'll try to come back with more details soon.

  Thanks for your attention and possible feedback!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1

[Qemu-devel] Fwd: Re: [PATCH 4/7] ati-vga: Fix cursor color with guest_hwcursor=true

[Andrew Randrianasulu]

--  Пересланное сообщение  --

Тема: Re: [Qemu-devel] [PATCH 4/7] ati-vga: Fix cursor color with 
guest_hwcursor=true
Дата: Понедельник 12 августа 2019
Отправитель: Andrew Randrianasulu 
Получатель:  BALATON Zoltan 

В сообщении от Monday 12 August 2019 13:55:45 BALATON Zoltan написал(а):
> On Mon, 12 Aug 2019, Philippe Mathieu-Daudé wrote:
> > On 8/12/19 12:28 PM, BALATON Zoltan wrote:
> >> On Mon, 12 Aug 2019, Philippe Mathieu-Daudé wrote:
> >>> On 8/11/19 11:14 PM, BALATON Zoltan wrote:
> >>>> Fixes: a38127414bd007c5b6ae64c664d9e8839393277e
> >>>> Signed-off-by: BALATON Zoltan 
> >>>> ---
> >>>> ?hw/display/ati.c | 2 +-
> >>>> ?1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/hw/display/ati.c b/hw/display/ati.c
> >>>> index 699f38223b..b849f5d510 100644
> >>>> --- a/hw/display/ati.c
> >>>> +++ b/hw/display/ati.c
> >>>> @@ -207,7 +207,7 @@ static void ati_cursor_draw_line(VGACommonState
> >>>> *vga, uint8_t *d, int scr_y)
> >>>>  }
> >>>>  } else {
> >>>>  color = (xbits & BIT(7) ? s->regs.cur_color1 :
> >>>> -? s->regs.cur_color0) << 8 |
> >>>> 0xff;
> >>>> +? s->regs.cur_color0) |
> >>>> 0xff00;
> >>>>  }
> >>>>  if (vga->hw_cursor_x + i * 8 + j >= h) {
> >>>>  return; /* end of screen, don't span to next line */
> >>>>
> >>>
> >>> Reviewed-by: Philippe Mathieu-Daudé 
> >>
> >> Thanks. I've noticed that cursor color may still be wrong with MacOS
> >> that uses big endian frame buffer so maybe this will also need to take
> >> frame buffer endianness into account somehow but this patch corrects a
> >> difference between guest_hwcursor true and false values, reproducible
> >> with some Linux versions (as far as I remember). While the wrong cursor
> >> color with MacOS is now consistent after this patch with both
> >> guest_hwcursor true or false so that likely needs a different fix that
> >> should be applied both to this place and to ati_cursor_define. (MacOS
> >> does not yet boot fully, it needs patches to OpenBIOS to be able to run
> >> an FCode ROM and will probably need the VBlank interrupt implemented in
> >> ati-vga without which it displays a desktop but freezes there).
> >
> > If you remember which Linux version had this problem, or you can link to
> > roms that behave incorrectly, please share, so we can add display
> > regression tests.
> 
> Unfortunately I don't. I think it was Andrew who found this so maybe he 
> can remember.

Blue cursor was seen on specific dvd (x86) image I did for myself, 
because it was  using plain X cursor (arrow or X-shaped), not colored 
versions used by default in many distributions.

may be 'startx -- -retro" will show it briefly too?

from man Xserver (1.19.7):

-retro  starts  the  server  with  the  classic stipple and cursor visible.  
The default is to start with a black root window, and to suppress display of 
the cursor until the
   first time an application calls XDefineCursor(). 


https://yadi.sk/d/F8cbINWzWJ-DkA

users: root and guest
passwords: toor and guest

You need to boot it to syslinux and type 'slax' there, because default will 
boot x86-64 kernel without aty128fb  (my fault)
Unfortunately, i don't have fresh qemu compiled (previous tests were done from 
tmpfs copy of qemu source tree),
 will recompile from git and re-test. from memory, loading aty128fb and
setting config fragment in /etc/X11/xorg.conf.d for EXA AccelMethod and "Option 
"UseFBDev" "1" ' allowed device (ati-vga) to work.

--

Update: qemu commit 864ab314f1d924129d06ac7b571f105a2b76a4b2 (tag: v4.1.0-rc4)
plus patch series by Zoltan 
(https://patchew.org/QEMU/cover.1565558093.git.balaton%40eik.bme.hu/)
actually boots my x86 dvd image with this command:

x86_64-softmmu/qemu-system-x86_64 -m 512 -enable-kvm -device 
ati-vga,guest_hwcursor=true -cdrom /mnt/sdb1/slax-14_06_2019-private0.iso

or
x86_64-softmmu/qemu-system-x86_64 -m 512 -enable-kvm -device 
ati-vga,guest_hwcursor=true -cdrom /mnt/sdb1/slax-14_06_2019-private0.iso 
-display sdl,gl=on

Cursor is normally-colored, but you need something like "xrandr -s 23" because 
default resolution a bit too big. 
(after modprobe aty128fb + usual xorg.conf dance about UseFBDev)

end of update



> 
> (You may also need latest vgabios-ati.bin from Gerd's repo to get Linux 
> drivers load and for rage128p that has to be in pc-bios dir because PCI 
> IDs are only patched in that way.)
> 
> Regards,
> BALATON Zoltan



---

Re: [Qemu-devel] [PATCH 4/7] ati-vga: Fix cursor color with guest_hwcursor=true

[Andrew Randrianasulu]

В сообщении от Monday 12 August 2019 13:55:45 BALATON Zoltan написал(а):
> On Mon, 12 Aug 2019, Philippe Mathieu-Daudé wrote:
> > On 8/12/19 12:28 PM, BALATON Zoltan wrote:
> >> On Mon, 12 Aug 2019, Philippe Mathieu-Daudé wrote:
> >>> On 8/11/19 11:14 PM, BALATON Zoltan wrote:
>  Fixes: a38127414bd007c5b6ae64c664d9e8839393277e
>  Signed-off-by: BALATON Zoltan 
>  ---
>  ?hw/display/ati.c | 2 +-
>  ?1 file changed, 1 insertion(+), 1 deletion(-)
> 
>  diff --git a/hw/display/ati.c b/hw/display/ati.c
>  index 699f38223b..b849f5d510 100644
>  --- a/hw/display/ati.c
>  +++ b/hw/display/ati.c
>  @@ -207,7 +207,7 @@ static void ati_cursor_draw_line(VGACommonState
>  *vga, uint8_t *d, int scr_y)
>   }
>   } else {
>   color = (xbits & BIT(7) ? s->regs.cur_color1 :
>  -? s->regs.cur_color0) << 8 |
>  0xff;
>  +? s->regs.cur_color0) |
>  0xff00;
>   }
>   if (vga->hw_cursor_x + i * 8 + j >= h) {
>   return; /* end of screen, don't span to next line */
> 
> >>>
> >>> Reviewed-by: Philippe Mathieu-Daudé 
> >>
> >> Thanks. I've noticed that cursor color may still be wrong with MacOS
> >> that uses big endian frame buffer so maybe this will also need to take
> >> frame buffer endianness into account somehow but this patch corrects a
> >> difference between guest_hwcursor true and false values, reproducible
> >> with some Linux versions (as far as I remember). While the wrong cursor
> >> color with MacOS is now consistent after this patch with both
> >> guest_hwcursor true or false so that likely needs a different fix that
> >> should be applied both to this place and to ati_cursor_define. (MacOS
> >> does not yet boot fully, it needs patches to OpenBIOS to be able to run
> >> an FCode ROM and will probably need the VBlank interrupt implemented in
> >> ati-vga without which it displays a desktop but freezes there).
> >
> > If you remember which Linux version had this problem, or you can link to
> > roms that behave incorrectly, please share, so we can add display
> > regression tests.
> 
> Unfortunately I don't. I think it was Andrew who found this so maybe he 
> can remember.

Blue cursor was seen on specific dvd (x86) image I did for myself, 
because it was  using plain X cursor (arrow or X-shaped), not colored 
versions used by default in many distributions.

may be 'startx -- -retro" will show it briefly too?

from man Xserver (1.19.7):

-retro  starts  the  server  with  the  classic stipple and cursor visible.  
The default is to start with a black root window, and to suppress display of 
the cursor until the
   first time an application calls XDefineCursor(). 


https://yadi.sk/d/F8cbINWzWJ-DkA

users: root and guest
passwords: toor and guest

You need to boot it to syslinux and type 'slax' there, because default will 
boot x86-64 kernel without aty128fb  (my fault)
Unfortunately, i don't have fresh qemu compiled (previous tests were done from 
tmpfs copy of qemu source tree),
 will recompile from git and re-test. from memory, loading aty128fb and
setting config fragment in /etc/X11/xorg.conf.d for EXA AccelMethod and "Option 
"UseFBDev" "1" ' allowed device (ati-vga) to work.



> 
> (You may also need latest vgabios-ati.bin from Gerd's repo to get Linux 
> drivers load and for rage128p that has to be in pc-bios dir because PCI 
> IDs are only patched in that way.)
> 
> Regards,
> BALATON Zoltan

[Qemu-devel] [Bug 1837049] Re: qemu-system-ppc segfaults with -display sdl

[Andrew Randrianasulu]

Hello, Richard!
No, same bug was biting me without any specific options, i tried to add -Og for 
better debugging, but backtrace was anyway not complete ... I think I can live 
with -display gtk workaround for now.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1837049

Title:
  qemu-system-ppc segfaults with -display sdl

Status in QEMU:
  New

Bug description:
  Hello.

  I was trying to debug this segfault:
  https://lists.nongnu.org/archive/html/qemu-ppc/2019-07/msg00186.html

  I recompiled latest qemu from git (commit 
0b18cfb8f1828c905139b54c8644b0d8f4aad879 ), using this configure line:
  ./configure --target-list=i386-softmmu,x86_64-softmmu,ppc-softmmu 
--audio-drv-list=alsa --disable-werror --extra-cflags="-Og" --enable-debug-tcg

  after this I tried original line under gdb, it was still segfaulting:

  --copy-
  gdb ./ppc-softmmu/qemu-system-ppc
  GNU gdb (GDB) 7.11.1
  Copyright (C) 2016 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "i586-slackware-linux".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .
  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ./ppc-softmmu/qemu-system-ppc...done.
  warning: File "/dev/shm/qemu/.gdbinit" auto-loading has been declined by your 
`auto-load safe-path' set to "$debugdir:$datadir/auto-load".
  To enable execution of this file add
  add-auto-load-safe-path /dev/shm/qemu/.gdbinit
  line to your configuration file "/home/guest/.gdbinit".
  To completely disable this security protection add
  set auto-load safe-path /
  line to your configuration file "/home/guest/.gdbinit".
  For more information about this security protection see the
  "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
  info "(gdb)Auto-loading safe path"
  (gdb) run  -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom 
/mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl,gl=on 
-vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370
  Starting program: /dev/shm/qemu/ppc-softmmu/qemu-system-ppc -M mac99,via=pmu 
-L ../queue-vga/pc-bios -cdrom 
/mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl,gl=on 
-vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/libthread_db.so.1".
  [New Thread 0xf560cb40 (LWP 8100)]
  [New Thread 0xf4c1ab40 (LWP 8101)]
  [New Thread 0xec1b7b40 (LWP 8102)]
  [New Thread 0xc5821b40 (LWP 8104)]
  [Thread 0xf4c1ab40 (LWP 8101) exited]
  [New Thread 0xf4c1ab40 (LWP 8119)]

  Thread 4 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0xec1b7b40 (LWP 8102)]
  0xf26c2e44 in code_gen_buffer ()
  (gdb) bt full
  #0  0x in code_gen_buffer ()
  #1  0x56710cf6 in cpu_exec (itb=, cpu=) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:173
  env = 
  ret = 
  last_tb = 
  tb_exit = 
  tb_ptr = 0xf26c2cc0  "‹]ш…Ы\017ЊБ\020"
  ret = 0
  insns_left = 
  cflags = 
  tb = 0x5722fe58
  last_tb = 
  tb_exit = 
  cc = 
  __func__ = "cpu_exec"
  ret = 
  sc = 
  #2  0x56710cf6 in cpu_exec (tb_exit=, last_tb=, tb=, cpu=) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:621
  ret = 0
  insns_left = 
  cflags = 
  tb = 0x5722fe58
  last_tb = 
  tb_exit = 
  cc = 
  __func__ = "cpu_exec"
  ret = 
  sc = 
  #3  0x56710cf6 in cpu_exec (cpu=0x573db8f8) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:732
  cflags = 
  tb = 0x5722fe58
  last_tb = 
  tb_exit = 
  cc = 
  __func__ = "cpu_exec"
  ret = 
  sc = 
  #4  0x566cfade in tcg_cpu_exec (cpu=0x573db8f8) at /dev/shm/qemu/cpus.c:1435
  ret = 
  #5  0x566d1e6d in qemu_tcg_rr_cpu_thread_fn (arg=0x573db8f8) at 
/dev/shm/qemu/cpus.c:1537
  r = 
  cpu = 0x573db8f8
  __PRETTY_FUNCTION__ = "qemu_tcg_rr_cpu_thread_fn"
  #6  0x56b56fe0 in qemu_thread_start (args=0x57400668) at 
util/qemu-thread-posix.c:502
  __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1461911128, 
1463813736, 1461911128, -333745816, 247778263, 1392237730}, __mask_was_saved = 
0}},

[Qemu-devel] [Bug 1837049] [NEW] qemu-system-ppc segfaults with -display sdl

[Andrew Randrianasulu]

Public bug reported:

Hello.

I was trying to debug this segfault:
https://lists.nongnu.org/archive/html/qemu-ppc/2019-07/msg00186.html

I recompiled latest qemu from git (commit 
0b18cfb8f1828c905139b54c8644b0d8f4aad879 ), using this configure line:
./configure --target-list=i386-softmmu,x86_64-softmmu,ppc-softmmu 
--audio-drv-list=alsa --disable-werror --extra-cflags="-Og" --enable-debug-tcg

after this I tried original line under gdb, it was still segfaulting:

--copy-
gdb ./ppc-softmmu/qemu-system-ppc
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-slackware-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./ppc-softmmu/qemu-system-ppc...done.
warning: File "/dev/shm/qemu/.gdbinit" auto-loading has been declined by your 
`auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /dev/shm/qemu/.gdbinit
line to your configuration file "/home/guest/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/guest/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) run  -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom 
/mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl,gl=on 
-vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370
Starting program: /dev/shm/qemu/ppc-softmmu/qemu-system-ppc -M mac99,via=pmu -L 
../queue-vga/pc-bios -cdrom /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso 
-m 512 -display sdl,gl=on -vga std -d guest_errors,unimp -boot d -cpu G4 -g 
1024x768x24 -device ES1370
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0xf560cb40 (LWP 8100)]
[New Thread 0xf4c1ab40 (LWP 8101)]
[New Thread 0xec1b7b40 (LWP 8102)]
[New Thread 0xc5821b40 (LWP 8104)]
[Thread 0xf4c1ab40 (LWP 8101) exited]
[New Thread 0xf4c1ab40 (LWP 8119)]

Thread 4 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xec1b7b40 (LWP 8102)]
0xf26c2e44 in code_gen_buffer ()
(gdb) bt full
#0  0x in code_gen_buffer ()
#1  0x56710cf6 in cpu_exec (itb=, cpu=) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:173
env = 
ret = 
last_tb = 
tb_exit = 
tb_ptr = 0xf26c2cc0  "‹]ш…Ы\017ЊБ\020"
ret = 0
insns_left = 
cflags = 
tb = 0x5722fe58
last_tb = 
tb_exit = 
cc = 
__func__ = "cpu_exec"
ret = 
sc = 
#2  0x56710cf6 in cpu_exec (tb_exit=, last_tb=, tb=, cpu=) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:621
ret = 0
insns_left = 
cflags = 
tb = 0x5722fe58
last_tb = 
tb_exit = 
cc = 
__func__ = "cpu_exec"
ret = 
sc = 
#3  0x56710cf6 in cpu_exec (cpu=0x573db8f8) at 
/dev/shm/qemu/accel/tcg/cpu-exec.c:732
cflags = 
tb = 0x5722fe58
last_tb = 
tb_exit = 
cc = 
__func__ = "cpu_exec"
ret = 
sc = 
#4  0x566cfade in tcg_cpu_exec (cpu=0x573db8f8) at /dev/shm/qemu/cpus.c:1435
ret = 
#5  0x566d1e6d in qemu_tcg_rr_cpu_thread_fn (arg=0x573db8f8) at 
/dev/shm/qemu/cpus.c:1537
r = 
cpu = 0x573db8f8
__PRETTY_FUNCTION__ = "qemu_tcg_rr_cpu_thread_fn"
#6  0x56b56fe0 in qemu_thread_start (args=0x57400668) at 
util/qemu-thread-posix.c:502
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1461911128, 
1463813736, 1461911128, -333745816, 247778263, 1392237730}, __mask_was_saved = 
0}}, __pad = {0xec1b70d0, 0x0, 0x0, 0x0}}
__cancel_routine = 0x56b57040 
__not_first_call = 
qemu_thread_args = 0x57400668
start_routine = 0x566d1a30 
arg = 0x573db8f8
r = 
#7  0x in start_thread () at /lib/libpthread.so.0
#8  0x in clone () at /lib/libc.so.6
(gdb) quit
A debugging session is active.

Inferior 1 [process 8096] will be killed.

Quit anyway? (y or n) y
--copy end--

But when I take away -display sdl, or replace it with -display gtk -
same line was booting to desktop!

Changing cpu to G3 also allowed boot:

./ppc-soft

[Qemu-devel] [Bug 1831545] Re: "accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86 host

[Andrew Randrianasulu]

bug fixed in current git (commit
474f3938d79ab36b9231c9ad3b5a9314c2aeacde). Thanks, Alex!

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1831545

Title:
  "accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86
  host

Status in QEMU:
  In Progress

Bug description:
  As described in https://lists.gnu.org/archive/html/qemu-
  devel//2019-05/msg07362.html I run into TCG regression in qemu-git.

  Unfortunately, fix from bug
  https://bugs.launchpad.net/qemu/+bug/1830872 seems to be nonn-
  effective for my case.

  For reproduction (on 32-bit x86 host, in my case Slackware with gcc
  5.5.0):

  ./configure --target-list=x86_64-softmmu --disable-werror --enable-
  debug-tcg

  make (-j5 in my case)

  try to boot any 64-bit kernel:

  x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64
  -accel tcg

  result is - qemu appear to hang right after "Booting the kernel" line.
  Decompression (xz) was ok.

  Tested with qemu-git commit  e2a58ff493a2e00db3e963c1839c5374500110f2

  32-bit OS can be booted fine, and -enable-kvm also allow 64 bit
  kernel/os to boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1831545/+subscriptions

Re: [Qemu-devel] [PATCH] cputlb: cast size_t to target_ulong before using for address masks

[Andrew Randrianasulu]

В сообщении от Thursday 06 June 2019 20:04:07 Alex Bennée написал(а):
> 
> Andrew Randrianasulu  writes:
> 
> > В сообщении от Thursday 06 June 2019 18:43:10 Alex Bennée написал(а):
> >> addr1 = addr & ~((target_ulong)size - 1);
> >
> > yes, this fixes my hang! Thanks!
> 
> Can I take that as a:
> 
> Tested-by: Andrew Randrianasulu 
> 
> ?

Yes, while I only tested 64-bit x86-64 kernel on 32-bit x86 host, not other 
machines.

> 
> --
> Alex Bennée
> 

Re: [Qemu-devel] [PATCH] cputlb: cast size_t to target_ulong before using for address masks

[Andrew Randrianasulu]

В сообщении от Thursday 06 June 2019 18:43:10 Alex Bennée написал(а):
> addr1 = addr & ~((target_ulong)size - 1);

yes, this fixes my hang! Thanks!

[Qemu-devel] [Bug 1831545] [NEW] "accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86 host

[Andrew Randrianasulu]

Public bug reported:

As described in https://lists.gnu.org/archive/html/qemu-
devel//2019-05/msg07362.html I run into TCG regression in qemu-git.

Unfortunately, fix from bug https://bugs.launchpad.net/qemu/+bug/1830872
seems to be nonn-effective for my case.

For reproduction (on 32-bit x86 host, in my case Slackware with gcc
5.5.0):

./configure --target-list=x86_64-softmmu --disable-werror --enable-
debug-tcg

make (-j5 in my case)

try to boot any 64-bit kernel:

x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64
-accel tcg

result is - qemu appear to hang right after "Booting the kernel" line.
Decompression (xz) was ok.

Tested with qemu-git commit  e2a58ff493a2e00db3e963c1839c5374500110f2

32-bit OS can be booted fine, and -enable-kvm also allow 64 bit
kernel/os to boot.

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: regression

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1831545

Title:
  "accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86
  host

Status in QEMU:
  New

Bug description:
  As described in https://lists.gnu.org/archive/html/qemu-
  devel//2019-05/msg07362.html I run into TCG regression in qemu-git.

  Unfortunately, fix from bug
  https://bugs.launchpad.net/qemu/+bug/1830872 seems to be nonn-
  effective for my case.

  For reproduction (on 32-bit x86 host, in my case Slackware with gcc
  5.5.0):

  ./configure --target-list=x86_64-softmmu --disable-werror --enable-
  debug-tcg

  make (-j5 in my case)

  try to boot any 64-bit kernel:

  x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64
  -accel tcg

  result is - qemu appear to hang right after "Booting the kernel" line.
  Decompression (xz) was ok.

  Tested with qemu-git commit  e2a58ff493a2e00db3e963c1839c5374500110f2

  32-bit OS can be booted fine, and -enable-kvm also allow 64 bit
  kernel/os to boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1831545/+subscriptions

[Qemu-devel] [Bug 1830872] Re: AARCH64 to ARMv7 mistranslation in TCG

[Andrew Randrianasulu]

** Attachment added: "bzImage-4.12.0-x64"
   
https://bugs.launchpad.net/bugs/1830872/+attachment/5268560/+files/bzImage-4.12.0-x64

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1830872

Title:
  AARCH64 to ARMv7 mistranslation in TCG

Status in QEMU:
  New

Bug description:
  The following guest code:

  
https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S

  implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI
  Development Kit II) library function. (CopyMem() basically has memmove()
  semantics, to provide a standard C analog here.) The relevant functions
  are InternalMemCopyMem() and __memcpy().

  When TCG translates this aarch64 code to x86_64, everything works
  fine.

  When TCG translates this aarch64 code to ARMv7, the destination area of
  the translated CopyMem() function becomes corrupted -- it differs from
  the intended source contents. Namely, in every 4096 byte block, the
  8-byte word at offset 4032 (0xFC0) is zeroed out in the destination,
  instead of receiving the intended source value.

  I'm attaching two hexdumps of the same destination area:

  - "good.txt" is a hexdump of the destination area when CopyMem() was
translated to x86_64,

  - "bad.txt" is a hexdump of the destination area when CopyMem() was
translated to ARMv7.

  In order to assist with the analysis of this issue, I disassembled the
  aarch64 binary with "objdump". Please find the listing in
  "DxeCore.objdump", attached. The InternalMemCopyMem() function starts at
  hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180.

  And, I ran the guest on the ARMv7 host with "-d
  in_asm,op,op_opt,op_ind,out_asm". Please find the log in
  "tcg.in_asm.op.op_opt.op_ind.out_asm.log", attached.

  The TBs that correspond to (parts of) the InternalMemCopyMem() and
  __memcpy() functions are scattered over the TCG log file, but the offset
  between the "nice" disassembly from "DxeCore.objdump", and the in-RAM
  TBs in the TCG log, can be determined from the fact that there is a
  single prfm instruction in the entire binary. The instruction's offset
  is 0x2b180 in "DxeCore.objdump" -- at the beginning of the __memcpy()
  function --, and its RAM address is 0x472d2180 in the TCG log. Thus the
  difference (= the load address of DxeCore.efi) is 0x472a7000.

  QEMU was built at commit a4f667b67149 ("Merge remote-tracking branch
  'remotes/cohuck/tags/s390x-20190521-3' into staging", 2019-05-21).

  The reproducer command line is (on an ARMv7 host):

qemu-system-aarch64 \
  -display none \
  -machine virt,accel=tcg \
  -nodefaults \
  -nographic \
  -drive 
if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \
  -drive 
if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \
  -cpu cortex-a57 \
  -chardev stdio,signal=off,mux=on,id=char0 \
  -mon chardev=char0,mode=readline \
  -serial chardev:char0

  The apparent symptom is an assertion failure *in the guest*, such as

  > ASSERT [DxeCore]
  > 
/home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090):
  > Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength

  but that is only a (distant) consequence of the CopyMem()
  mistranslation, and resultant destination area corruption.

  Originally reported in the following two mailing list messages:
  - 9d2e260c-c491-03d2-9b8b-b57b72083f77@redhat.com">http://mid.mail-archive.com/9d2e260c-c491-03d2-9b8b-b57b72083f77@redhat.com
  - f1cec8c0-1a9b-f5bb-f951-ea0ba9d276ee@redhat.com">http://mid.mail-archive.com/f1cec8c0-1a9b-f5bb-f951-ea0ba9d276ee@redhat.com

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1830872/+subscriptions

Re: [Qemu-devel] [Bug 1830872] Re: AARCH64 to ARMv7 mistranslation in TCG

[Andrew Randrianasulu]

В сообщении от Monday 03 June 2019 18:51:40 Alex Bennée написал(а):
> I managed to tweak the memory test enough to detect the failure on
> aarch64-on-armv7 and I the attached patch fixes it. Could you please
> double check with your test case?
> 


Hm, I manually applied path from LP(git diff disliked copypasted patch), 
so for now git diff in qemu tree shows:

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index cdcc377102..b796ab1cbe 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, 
TCGMemOpIdx oi,
 && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
 >= TARGET_PAGE_SIZE)) {
 target_ulong addr1, addr2;
-tcg_target_ulong r1, r2;
+uint64_t r1, r2;
 unsigned shift;
 do_unaligned_access:
 addr1 = addr & ~(size - 1);
lines 1-13/13 (END)  

-

but x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel 
tcg
still hangs at 'booting the kernel" (it decompress OK)

I make distclean'ed source tree and reconfigured it:
 ./configure --target-list=x86_64-softmmu --disable-werror --enable-debug-tcg  
--cross-cc-x86_64="/opt/kgcc64/bin/x86_64-unknown-linux-gnu-gcc-6.5.0"

next, make -j 5 and test.

Hm.

I tried debug switches, it seems to hang a bit differently for two runs:

x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64
-accel tcg -nographic -d in_asm,op,op_opt,op_ind,out_asm

=

IN:
0x810e8a63:  48 83 c3 64  addq $0x64, %rbx
0x810e8a67:  eb c2jmp  0x810e8a2b

OP:
 ld_i32 tmp18,env,$0xfff0
 movi_i32 tmp19,$0x0
 brcond_i32 tmp18,tmp19,lt,$L0

  810e8a63 
 movi_i32 tmp2,$0x64
 movi_i32 tmp3,$0x0
 mov_i32 tmp0,rbx_0
 mov_i32 tmp1,rbx_1
 add2_i32 tmp0,tmp1,tmp0,tmp1,tmp2,tmp3
 mov_i32 rbx_0,tmp0
 mov_i32 rbx_1,tmp1
 mov_i32 cc_src_0,tmp2
 mov_i32 cc_src_1,tmp3
 mov_i32 cc_dst_0,tmp0
 mov_i32 cc_dst_1,tmp1
 discard cc_src2_0
 discard cc_src2_1
 discard cc_op

  810e8a67 0009
 movi_i32 cc_op,$0x9
 goto_tb $0x0
 movi_i32 tmp6,$0x810e8a2b
 movi_i32 tmp7,$0x
 st_i32 tmp6,env,$0x80
 st_i32 tmp7,env,$0x84
 exit_tb $0xf2f1c080
 set_label $L0
 exit_tb $0xf2f1c083

OP after optimization and liveness analysis:
 ld_i32 tmp18,env,$0xfff0 dead: 1  pref=0xff
 movi_i32 tmp19,$0x0  pref=0xff
 brcond_i32 tmp18,tmp19,lt,$L0dead: 0 1

  810e8a63 
 movi_i32 tmp2,$0x64  pref=0xff
 movi_i32 tmp3,$0x0   pref=0xff
 add2_i32 tmp0,tmp1,rbx_0,rbx_1,tmp2,tmp3  dead: 2 3  pref=0xff,0xff
 mov_i32 rbx_0,tmp0   sync: 0  dead: 1  pref=0xff
 mov_i32 rbx_1,tmp1   sync: 0  dead: 1  pref=0xff
 mov_i32 cc_src_0,tmp2sync: 0  dead: 0 1  pref=0xff
 mov_i32 cc_src_1,tmp3sync: 0  dead: 0 1  pref=0xff
 mov_i32 cc_dst_0,rbx_0   sync: 0  dead: 0 1  pref=0xff
 mov_i32 cc_dst_1,rbx_1   sync: 0  dead: 0 1  pref=0xff
 discard cc_src2_0pref=0xff
 discard cc_src2_1pref=0xff
 discard cc_oppref=0xff mov_i32 cc_dst_0,tmp0
 mov_i32 cc_dst_1,tmp1
 discard cc_src2_0
 discard cc_src2_1
 discard cc_op

  810e8a55 0021
 movi_i32 cc_op,$0x21
 movi_i32 tmp20,$0x0
 movi_i32 tmp21,$0x0
 brcond2_i32 cc_dst_0,cc_dst_1,tmp20,tmp21,eq,$L1
 goto_tb $0x0
 movi_i32 tmp6,$0x810e8a57
 movi_i32 tmp7,$0x
 st_i32 tmp6,env,$0x80
 st_i32 tmp7,env,$0x84
 exit_tb $0xf2f1c180
 set_label $L1
 goto_tb $0x1
 movi_i32 tmp6,$0x810e8a63
 movi_i32 tmp7,$0x
 st_i32 tmp6,env,$0x80
 st_i32 tmp7,env,$0x84
 exit_tb $0xf2f1c181
 set_label $L0
 exit_tb $0xf2f1c183

OP after optimization and liveness analysis:
 ld_i32 tmp18,env,$0xfff0 dead: 1  pref=0xff
 movi_i32 tmp19,$0x0  pref=0xff
 brcond_i32 tmp18,tmp19,lt,$L0dead: 0 1

  810e8a4c 

  810e8a52 
 movi_i32 tmp1,$0x0   pref=0xff
 movi_i32 tmp0,$0x64  pref=0xff
 mov_i32 r14_0,tmp0   sync: 0  dead: 1  pref=0xf8
 mov_i32 r14_1,tmp1   sync: 0  dead: 1  pref=0xf8
 call 
cc_compute_c,$0x5,$2,cc_src_0,cc_src_1,cc_dst_0,cc_dst_1,cc_src_0,cc_src_1,cc_src2_0,cc_src2_1,cc_op
  sync: 0 1  dead: 0 1 2 3 4 5 6 7 8  pref=none,none
 mov_i32 cc_dst_0,r14_0   sync: 0  dead: 0 1  pref=0xff
 mov_i32 cc_dst_1,r14_1   sync: 0  dead: 0 1  pref=0xffУбито

(killed by me)

==

IN:
0x810e8a61:  eb efjmp  0x810e8a52

OP:
 ld_i32 tmp18,env,$0xfff0
 movi_i32 tmp19,$0x0
 brcond_i32 tmp18,tmp19,lt,$L0

  810e

Re: [Qemu-devel] [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load

[Andrew Randrianasulu]

В сообщении от Monday 03 June 2019 18:01:20 Alex Bennée написал(а):
> When running on 32 bit TCG backends a wide unaligned load ends up
> truncating data before returning to the guest. We specifically have
> the return type as uint64_t to avoid any premature truncation so we
> should use the same for the interim types.
> 
> Hopefully fixes #1830872
> 
> Signed-off-by: Alex Bennée 
> ---
>  accel/tcg/cputlb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
> index cdcc3771020..b796ab1cbea 100644
> --- a/accel/tcg/cputlb.c
> +++ b/accel/tcg/cputlb.c
> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, 
> TCGMemOpIdx oi,
>  && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
>  >= TARGET_PAGE_SIZE)) {
>  target_ulong addr1, addr2;
> -tcg_target_ulong r1, r2;
> +uint64_t r1, r2;
>  unsigned shift;
>  do_unaligned_access:
>  addr1 = addr & ~(size - 1);

Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64  so, my bug is 
separate from #1830872 ?

I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 
cross-compiler ..
probably x86-64 testing on i686 requires either docker (I don't have this
) or 'real' cross-compiler (build with glibc support).

Re: [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64

[Andrew Randrianasulu]

> Could you run:

>  make check-tcg

> And report which tests (if any) fail?

Unfortunately, test was SKIPped:

make check-tcg
make[1]: Вход в каталог `/dev/shm/qemu/slirp'
make[1]: Цель `all' не требует выполнения команд.
make[1]: Выход из каталога `/dev/shm/qemu/slirp'
CHK version_gen.h
  BUILD   TCG tests for x86_64-softmmu
  BUILD   x86_64 guest-tests SKIPPED
  RUN TCG tests for x86_64-softmmu
  RUN tests for x86_64 SKIPPED

[Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64

[Andrew Randrianasulu]

Hello!

I was compiling latest qemu git, and was surprized to find qemu-system-x86_64
(compiled for 32-bit x86 machine) can't boot any 64-bit kernel anymore.

32-bit kernels and kvm were fine.
So, I run git bisect

./configure --target-list=x86_64-softmmu --disable-werror 

make -j 5

x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg

git bisect log
git bisect start
# bad: [60905286cb5150de854e08279bca7dfc4b549e91] Merge remote-tracking branch 
'remotes/dgibson/tags/ppc-for-4.1-20190529' into staging
git bisect bad 60905286cb5150de854e08279bca7dfc4b549e91
# good: [32a1a94dd324d33578dca1dc96d7896a0244d768] Update version for v3.1.0 
release
git bisect good 32a1a94dd324d33578dca1dc96d7896a0244d768
# good: [32a1a94dd324d33578dca1dc96d7896a0244d768] Update version for v3.1.0 
release
git bisect good 32a1a94dd324d33578dca1dc96d7896a0244d768
# good: [9403bccfe3e271f04e12c8c64d306e0cff589009] Merge remote-tracking branch 
'remotes/pmaydell/tags/pull-target-arm-20190228-1' into staging
git bisect good 9403bccfe3e271f04e12c8c64d306e0cff589009
# good: [9403bccfe3e271f04e12c8c64d306e0cff589009] Merge remote-tracking branch 
'remotes/pmaydell/tags/pull-target-arm-20190228-1' into staging
git bisect good 9403bccfe3e271f04e12c8c64d306e0cff589009
# good: [a39286dd61e455014694cb6aa44cfa9e5c86d101] nbd: Tolerate some server 
non-compliance in NBD_CMD_BLOCK_STATUS
git bisect good a39286dd61e455014694cb6aa44cfa9e5c86d101
# bad: [bab1671f0fa928fd678a22f934739f06fd5fd035] tcg: Manually expand 
INDEX_op_dup_vec
git bisect bad bab1671f0fa928fd678a22f934739f06fd5fd035
# bad: [bab1671f0fa928fd678a22f934739f06fd5fd035] tcg: Manually expand 
INDEX_op_dup_vec
git bisect bad bab1671f0fa928fd678a22f934739f06fd5fd035
# good: [956fe143b4f254356496a0a1c479fa632376dfec] target/arm: Implement VLLDM 
for v7M CPUs with an FPU
git bisect good 956fe143b4f254356496a0a1c479fa632376dfec
# good: [df06df4f412a67341de0fbb075e74c4dde3c8972] Merge remote-tracking branch 
'remotes/ericb/tags/pull-nbd-2019-05-07' into staging
git bisect good df06df4f412a67341de0fbb075e74c4dde3c8972
# good: [e5a0a6784a63a15d5b1221326fe5c258be6b5561] vvfat: Replace 
bdrv_{read,write}() with bdrv_{pread,pwrite}()
git bisect good e5a0a6784a63a15d5b1221326fe5c258be6b5561
# bad: [01807c8b0e9f5da6981c2e62a3c1d8f661fb178e] Merge remote-tracking branch 
'remotes/armbru/tags/pull-misc-2019-05-13' into staging
git bisect bad 01807c8b0e9f5da6981c2e62a3c1d8f661fb178e
# bad: [04d6556c5c91d6b00c70df7b85e1715a7c7870df] Merge remote-tracking branch 
'remotes/stsquad/tags/pull-demacro-softmmu-100519-1' into staging
git bisect bad 04d6556c5c91d6b00c70df7b85e1715a7c7870df
# good: [c9ba36ff2f56a95dec0ee47f4dab0b22a0a01f86] Merge remote-tracking branch 
'remotes/kevin/tags/for-upstream' into staging
git bisect good c9ba36ff2f56a95dec0ee47f4dab0b22a0a01f86
# bad: [fc1bc777910dc14a3db4e2ad66f3e536effc297d] cputlb: Drop attribute flatten
git bisect bad fc1bc777910dc14a3db4e2ad66f3e536effc297d
# bad: [f1be36969de2fb9b6b64397db1098f115210fcd9] cputlb: Move TLB_RECHECK 
handling into load/store_helper
git bisect bad f1be36969de2fb9b6b64397db1098f115210fcd9
# bad: [eed5664238ea5317689cf32426d9318686b2b75c] accel/tcg: demacro cputlb
git bisect bad eed5664238ea5317689cf32426d9318686b2b75c
# first bad commit: [eed5664238ea5317689cf32426d9318686b2b75c] accel/tcg: 
demacro cputlb

Not sure how many people test qemu-system-x86_64 on 32-bit x86 hosts

 gcc --version
gcc (GCC) 5.5.0

commit log says

-
accel/tcg: demacro cputlb

Instead of expanding a series of macros to generate the load/store
helpers we move stuff into common functions and rely on the compiler
to eliminate the dead code for each variant.
--

May be gcc 5.5.0 was not really good in this case ...

Re: [Qemu-devel] [ANNOUNCE] QEMU 4.0.0-rc3 is now available

[Andrew Randrianasulu]

В сообщении от Thursday 11 April 2019 12:14:45 Peter Maydell написал(а):
> On Wed, 10 Apr 2019 at 22:51, Andrew Randrianasulu
>  wrote:
> >
> > Please also include this patch in next -rc or final, it fixes 32-bit 
> > compilation:
> >
> > https://patchew.org/QEMU/20190402073018.17747-1-kraxel%40redhat.com/
> > ([Qemu-devel] [PATCH] curses: fix wchar_t printf warning)
> >
> > without it I get
> >
> > ui/curses.c: In function 'get_ucs':
> > ui/curses.c:456:25: error: format '%x' expects argument of type 'unsigned 
> > int', but argument 3 has type 'wchar_t {aka long int}' [-Werror=format=]
> >  fprintf(stderr, "Could not convert 0x%02x from WCHAR_T to UCS-2: 
> > %s\n",
> >
> 
> Rats, I'd forgotten about that one. What platform does it fail
> to compile on, though? I test on 32-bit Linux and Windows compiles,
> and they work OK.

This is slackware (mix of many versions) + gcc (GCC) 5.5.0.
Probably, this error will not show up if you don't have ncurses-dev packages, 
so configure will NOT enable curses ui ?

> 
> Also, this will be only a warning, not a compile error, in the
> release build, so we could get away with releasing without
> the patch applied. We'll see if any other rc4 issues come up.
> 
> thanks
> -- PMM
> 

Re: [Qemu-devel] [ANNOUNCE] QEMU 4.0.0-rc3 is now available

[Andrew Randrianasulu]

Please also include this patch in next -rc or final, it fixes 32-bit 
compilation:

https://patchew.org/QEMU/20190402073018.17747-1-kraxel%40redhat.com/
([Qemu-devel] [PATCH] curses: fix wchar_t printf warning)

without it I get 

ui/curses.c: In function 'get_ucs':
ui/curses.c:456:25: error: format '%x' expects argument of type 'unsigned int', 
but argument 3 has type 'wchar_t {aka long int}' [-Werror=format=]
 fprintf(stderr, "Could not convert 0x%02x from WCHAR_T to UCS-2: %s\n",
 ^
cc1: all warnings being treated as errors
make: *** [ui/curses.o] Error 1
make: *** Waiting for unfinished jobs

Re: [Qemu-devel] Proof of concept for GPU forwarding for Linux guest on Linux host

[Andrew Randrianasulu]

В сообщении от Thursday 04 April 2019 10:33:55 Tao Wu(吴涛@Eng) написал(а):
> On Thu, Apr 4, 2019 at 12:15 AM Andrew Randrianasulu <
> randrianas...@gmail.com> wrote:
> 
> > Hi!
> >
> > I recall I saw something like this some time ago (but in connection with
> > qemu-user + ALSA sycallls)
> > So far I found this:
> >
> > https://marc.info/?l=qemu-devel&m=154349285205915
> >
> > List:   qemu-devel
> > Subject:[Qemu-devel] Support for Intel GPU
> > From:   Allan Sandfeld Jensen 
> > Date:   2018-11-29 11:54:19
> >
> > Ah, found alsa bits too:
> > https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg05334.html
> 
> Thanks, I took a look, the previous patches are targeting qemu user mode
> while mine is targeting full system virtualization.
> There is no plan to merge my code as it is now. I just want to get some
> feedbacks first.

I was thinking qemu's system mode was covered already by

https://www.kraxel.org/blog/2018/04/vgpu-display-support-finally-merged-upstream/
(intel's vGPU)

https://www.kraxel.org/blog/2016/09/using-virtio-gpu-with-libvirt-and-spice/
(virtio-gpu, via gallium framework)

?

But thanks anyway, may be some of those ideas can be fused together (I only 
have nvidia/nouveau GPU, 
and at best can forward-port something simple)


> 
> 
> >
> >
> > None of this was merged, as far as I understand.
> >
> 

Re: [Qemu-devel] Proof of concept for GPU forwarding for Linux guest on Linux host

[Andrew Randrianasulu]

Hi!

I recall I saw something like this some time ago (but in connection with 
qemu-user + ALSA sycallls)
So far I found this:

https://marc.info/?l=qemu-devel&m=154349285205915

List:   qemu-devel
Subject:[Qemu-devel] Support for Intel GPU
From:   Allan Sandfeld Jensen 
Date:   2018-11-29 11:54:19

Ah, found alsa bits too:
https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg05334.html

None of this was merged, as far as I understand.

Re: [Qemu-devel] [PATCH] Fix 32-bit compilation with gcc 5.5

[Andrew Randrianasulu]

В сообщении от Friday 29 March 2019 11:40:42 Alex Bennée написал(а):
> 
> Andrew Randrianasulu  writes:
> 
> > ---
> >  ui/curses.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ui/curses.c b/ui/curses.c
> > index cc6d6da684..b25814f3fb 100644
> > --- a/ui/curses.c
> > +++ b/ui/curses.c
> > @@ -453,7 +453,7 @@ static uint16_t get_ucs(wchar_t wch, iconv_t conv)
> >  swch = sizeof(wch);
> >
> >  if (iconv(conv, &pwch, &swch, &pch, &sch) == (size_t) -1) {
> > -fprintf(stderr, "Could not convert 0x%02x from WCHAR_T to UCS-2: 
> > %s\n",
> > +fprintf(stderr, "Could not convert 0x%02lx from WCHAR_T to UCS-2: 
> > %s\n",
> >  wch, strerror(errno));
> 
> This will break 64 bit compiles:
> 
>   ui/curses.c: In function ‘get_ucs’:
>   ui/curses.c:456:50: error: format ‘%lx’ expects argument of type ‘long 
> unsigned int’, but argument 3 has type ‘wchar_t’ {aka ‘int’} [-Werror=format=]
> 
> Annoyingly it seems wchar_t can be various sizes on various platforms.
> Maybe the simplest solution would be to upcast to a known size?
> 
> fprintf(stderr, "Could not convert %" PRIx32 " from WCHAR_T to UCS-2: 
> %s\n",
> (uint32_t) wch, strerror(errno));
> 
> >  return 0xFFFD;
> >  }
> 


This worked for me with 32-bit gcc. Thanks!

> 
> --
> Alex Bennée
> 

[Qemu-devel] [PATCH] Fix 32-bit compilation with gcc 5.5

[Andrew Randrianasulu]

---
 ui/curses.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ui/curses.c b/ui/curses.c
index cc6d6da684..b25814f3fb 100644
--- a/ui/curses.c
+++ b/ui/curses.c
@@ -453,7 +453,7 @@ static uint16_t get_ucs(wchar_t wch, iconv_t conv)
 swch = sizeof(wch);
 
 if (iconv(conv, &pwch, &swch, &pch, &sch) == (size_t) -1) {
-fprintf(stderr, "Could not convert 0x%02x from WCHAR_T to UCS-2: %s\n",
+fprintf(stderr, "Could not convert 0x%02lx from WCHAR_T to UCS-2: 
%s\n",
 wch, strerror(errno));
 return 0xFFFD;
 }
-- 
2.14.4

Re: [Qemu-devel] Set up github repo for pmon sources

[Andrew Randrianasulu]

В сообщении от Saturday 16 March 2019 20:53:01 вы написали:
> On 3/15/19 9:06 PM, Andrew Randrianasulu wrote:
> > https://github.com/Randrianasulu/pmon/commits/2014
> > 
> > hopefully it will stay this way.
> > 
> > Anyone know what license I must pick for this?
> > 3-clause BSD? 4-clause BSD? (from Copyright file it lists 4 terms)
> 
> 4-clause BSD is incompatible with the GPL, and thus cannot be used for
> qemu.  (2-clause and 3-clause are okay, though).
> 
> > 
> > 
> > *  $Id: Copyright,v 1.1.1.1 2006/09/14 01:59:06 root Exp $ */
> > 
> > /*
> >  * Copyright (c) 2000-2002 Opsycon AB  (www.opsycon.se)
> >  * Copyright (c) 2000 Rtmx, Inc   (www.rtmx.com)
> >  * Copyright (c) 2001 ipUnplugged AB (www.ipunplugged.com)
> >  *
> >  * Redistribution and use in source and binary forms, with or without
> >  * modification, are permitted provided that the following conditions
> >  * are met:
> >  * 1. Redistributions of source code must retain the above copyright
> >  *notice, this list of conditions and the following disclaimer.
> >  * 2. Redistributions in binary form must reproduce the above copyright
> >  *notice, this list of conditions and the following disclaimer in the
> >  *documentation and/or other materials provided with the distribution.
> >  * 3. All advertising materials mentioning features or use of this software
> >  *must display the following acknowledgement:
> >  *  This product includes software developed for Rtmx, Inc by
> >  *  Opsycon Open System Consulting AB, Sweden.
> >  *  This product includes software developed by Opsycon AB.
> >  *  This product includes software developed by ipUnplugged AB.
> 
> Indeed, this is the advertising clause of the 4-clause BSD, which
> renders this license unsuitable for use with GPL projects.

Ow. Ok, then I just leave it as-is, github already showing this text as 
license, 
and while qemu as project can't use this firmware - users still can.

Also, there seems to be another pmon branch on github:
https://github.com/jcowgill/pmon-loongson - but I haven't tested it.

Morever, what lives in 
http://www.anheng.com.cn/loongson/pmon/updates.lemote.com/files/upload/lm/firmware/pmon/source/

seems to be THIRD branch of pmon, at least radeon-specific file is different, 
and apparently solved bug I solved independently. (there was confusion between 
Bytes per pixel and Bits per pixel)

> 
> >  * 4. The name of the author may not be used to endorse or promote products
> >  *derived from this software without specific prior written permission.
> >  *
> 
> 

[Qemu-devel] Set up github repo for pmon sources

[Andrew Randrianasulu]

https://github.com/Randrianasulu/pmon/commits/2014

hopefully it will stay this way.

Anyone know what license I must pick for this?
3-clause BSD? 4-clause BSD? (from Copyright file it lists 4 terms)


*  $Id: Copyright,v 1.1.1.1 2006/09/14 01:59:06 root Exp $ */

/*
 * Copyright (c) 2000-2002 Opsycon AB  (www.opsycon.se)
 * Copyright (c) 2000 Rtmx, Inc   (www.rtmx.com)
 * Copyright (c) 2001 ipUnplugged AB (www.ipunplugged.com)
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *must display the following acknowledgement:
 *  This product includes software developed for Rtmx, Inc by
 *  Opsycon Open System Consulting AB, Sweden.
 *  This product includes software developed by Opsycon AB.
 *  This product includes software developed by ipUnplugged AB.
 * 4. The name of the author may not be used to endorse or promote products
 *derived from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
 * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
 * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *
 */


In theory master branch is newer, but it seems ubifs commit in early 2014 broke 
non-nand machines, so I was uanble to solve this. May be I should cherry-pick 
some  master commits to 2014 branch, but I don't know if they fix anything 
useful
for emulated machine or not.

Src where I got tarball with git:
http://www.anheng.com.cn/loongson/pmon/

[Qemu-devel] [PATCH v5-resend 0/2] Basic ATI VGA emulation

[Andrew Randrianasulu]

You can have my 
Tested-by: Andrew Randrianasulu, randrianas...@gmail.com

ref: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg01728.html
https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg01985.html

Re: [Qemu-devel] PMON2000 compilation and kernel question

[Andrew Randrianasulu]

> Checked off-list, just for the record: looks like your compiled binary tries 
> to set up a flat-panel display besides the CRT but flat-panel part of GPU is 
> not modelled and with both screens pmon tries to put CRT screen at an 80MB 
> offset which can't work as chip has only 16MB VRAM. This results in distorted 
> screen. I'm not sure why it does that but it shouldn't try to use flat-panel 
> display at the first place because fulong2e mini-pc QEMU tries to emulate is 
> not a laptop and has no flat panel. The pmon_2e.bin binary does not do this 
> and only creates a CRT screen at offset 0 so I think the config used to 
> compile pmon is not right yet.

May be I send you wrong binary :/
sorry, will double-check

distorted screen was when I tried 800x600 or 32 bpp 

sha256sum /dev/shm/pmon-my/pmon/zloader.2edev/pmon.bin
ecc82c621c33d140ac1ba01a70876f467e47a7cc9eb154a0647c227355d39e60  
/dev/shm/pmon-my/pmon/zloader.2edev/pmon.bin

https://ibin.co/4ZKKU0t9xNDE.png - image I got.

mac99 machine with your ati-vga device look like this (after upgrading X and 
r128 driver)
https://ibin.co/4ZKLzg90dFZA.png
note again, this is with NoAccel (while strangely overlay still around via 
xvinfo)

[Qemu-devel] [PATCH v5-resend 0/2] Basic ATI VGA emulation

[Andrew Randrianasulu]

Tried this with mac99 machine and lubuntu 16.04 ppc.

After upgrading r128 driver to -hwe part to get past this bug
https://bugs.freedesktop.org/show_bug.cgi?id=91622

and disabling accel I can see some image and cursor!

qemu command:

ppc64-softmmu/qemu-system-ppc64 -M mac99 -device ati-vga \
-cdrom /mnt/sdb1/ISO/lubuntu-16.04-desktop-powerpc.iso -m 1G -boot d -cpu g4 
-device usb-mouse -smp 1

model rv100 doesn't recognized by openfirmware, so no output from it.

Menus in wondows still at wrong place (not shown, even), but generally speaking 
some image is on screen.
[  6238.260] 
X.Org X Server 1.19.6
Release Date: 2017-12-20
[  6238.275] X Protocol Version 11, Revision 0
[  6238.280] Build Operating System: Linux 4.4.0-138-powerpc64-smp ppc Ubuntu
[  6238.283] Current Operating System: Linux lubuntu 4.4.0-21-powerpc-smp #37-Ubuntu SMP Mon Apr 18 18:33:34 UTC 2016 ppc
[  6238.284] Kernel command line: ro ramdisk_size=1048576 file=/cdrom/preseed/lubuntu.seed boot=casper quiet splash --- 
[  6238.302] Build Date: 25 October 2018  04:10:08PM
[  6238.306] xorg-server 2:1.19.6-1ubuntu4.1~16.04.2 (For technical support please see http://www.ubuntu.com/support) 
[  6238.313] Current version of pixman: 0.33.6
[  6238.325] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[  6238.326] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  6238.364] (==) Log file: "/var/log/Xorg.1.log", Time: Thu Mar  7 03:12:54 2019
[  6238.381] (==) Using config file: "/etc/X11/xorg.conf"
[  6238.387] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  6238.437] (==) ServerLayout "X.org Configured"
[  6238.439] (**) |-->Screen "Screen0" (0)
[  6238.440] (**) |   |-->Monitor "Monitor0"
[  6238.449] (**) |   |-->Device "Card0"
[  6238.451] (**) |-->Input Device "Mouse0"
[  6238.451] (**) |-->Input Device "Keyboard0"
[  6238.452] (==) Automatically adding devices
[  6238.452] (==) Automatically enabling devices
[  6238.452] (==) Automatically adding GPU devices
[  6238.452] (==) Automatically binding GPU devices
[  6238.454] (==) Max clients allowed: 256, resource mask: 0x1f
[  6238.456] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  6238.456] 	Entry deleted from font path.
[  6238.456] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[  6238.456] 	Entry deleted from font path.
[  6238.456] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[  6238.456] 	Entry deleted from font path.
[  6238.456] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist.
[  6238.457] 	Entry deleted from font path.
[  6238.457] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[  6238.457] 	Entry deleted from font path.
[  6238.457] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[  6238.457] 	Entry deleted from font path.
[  6238.457] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  6238.457] 	Entry deleted from font path.
[  6238.457] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[  6238.457] 	Entry deleted from font path.
[  6238.457] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[  6238.458] 	Entry deleted from font path.
[  6238.458] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist.
[  6238.458] 	Entry deleted from font path.
[  6238.458] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[  6238.458] 	Entry deleted from font path.
[  6238.458] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[  6238.458] 	Entry deleted from font path.
[  6238.458] (**) FontPath set to:
	/usr/share/fonts/X11/misc,
	built-ins,
	/usr/share/fonts/X11/misc,
	built-ins
[  6238.458] (**) ModulePath set to "/usr/lib/xorg/modules"
[  6238.459] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[  6238.459] (WW) Disabling Mouse0
[  6238.460] (WW) Disabling Keyboard0
[  6238.460] (II) Loader magic: 0x202ee710
[  6238.461] (II) Module ABI versions:
[  6238.461] 	X.Org ANSI C Emulation: 0.4
[  6238.461] 	X.Org Video Driver: 23.0
[  6238.461] 	X.Org XInput driver : 24.1
[  6238.461] 	X.Org Server Extension : 10.0
[  6238.669] (++) using VT number 2

[  6238.915] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_31
[  6239.091] (II) xfree86: Adding drm device (/dev/dri/card0)
[  6239.229] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 paused 0
[  6239.328] (--) PCI:*(0:0:15:0) 1002:5046:1af4:1100 rev 0, Mem @ 0x8100/16777216, 0x8200/16384, I/O @ 0x1000/256, BIOS @ 0x/65536
[  6239.341] (II) "glx" will be loaded. This was enabled by default and also specified in the config file.
[  6239.342] (II) LoadModule: "glx"
[  6239.389] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 

Re: [Qemu-devel] PMON2000 compilation and kernel question

[Andrew Randrianasulu]

> What do you mean by DIMM size not detected?

Sorry, I mean "No DIMM in slot 1" message.

PMON2000 MIPS Initializing. Standby...
ERRORPC= CONFIG=00030932
 PRID=6302
DIMM read
read memory type
read number of rows
read blocks per ddrram
read number of sides
read width
0002
No DIMM in slot 1
DIMM SIZE=1000
sdcfg=2d5043df
msize=1000
Init SDRAM Done!
Sizing caches...
Init caches...
godson2 caches found
Init caches done, cfg = 00030932

Copy PMON to execute location...
  start = 0x8100
  s0 = 0x3ec0
a105
copy text section done.
Copy PMON to execute location done.
sp=80ffc000Uncompressing BiosOK,Booting Bios

[...]

with binary I got:

PMON2000 MIPS Initializing. Standby...
ERRORPC= CONFIG=00030932
 PRID=6302
DIMM read
0080
read memory type
read number of rows
read memory size per side
read blocks per ddrram
read number of sides
read width
DIMM SIZE=1000
sdcfg=3d5043df
msize=1000
Init SDRAM Done!
Sizing caches...
Init caches...
godson2 caches found
Init caches done, cfg = 00030932

Copy PMON to execute location...
  start = 0x8500
  s0 = 0x3ac0
a504
copy text section done.
Copy PMON to execute location done.
sp=84ffc000Uncompressing BiosOK,Booting Bios


As far as I understand those values come from 
Targets/Bonito2edev/Bonito/start.S

#include "i2c.S"
beqz msize,.nodimm
nop
b 2f
nop
.nodimm:
movedbg,a0
PRINTSTR ("\r\nNo DIMM in all slots,use default configure\r\n")
li  msize,0x1000
li  sdCfg,0x055043df /* zgj-8-7-14-13 */
2:
PRINTSTR("DIMM SIZE=")
movea0,msize
bal hexserial
nop
PRINTSTR("\r\n")

li  t0, 0xbff8
sd  sdCfg, 0(t0)

 gx 2006-03-17: mode 
#li t1,0x20
li  t1,0x28
li  t0, 0xbff0
sw  t1,0(t0)
nop
li  t1,0x0
li  t0, 0xbff0
sw  t1,0x30(t0)
nop


and in turn i2c.S has this:

Targets/Bonito2edev/Bonito/i2c.S

#define i2cread newi2cread
li  msize,0
PRINTSTR("DIMM read\r\n")

/* only one memory slot, slave address is 101b */
li  sdCfg,0x0400 /*bit 26Н»·ўКЅ¶БРґК±µДїйДЪЛіРт*/
li  a1, 0x0
li  a0,0xa1
bal i2cread
nop
beq v0,0xff,1f
nop
beq v0,0x80,1f
nop
move a0,v0
bal hexserial
nop
PRINTSTR ("\r\nNo DIMM in slot 0 \r\n");
b 2f
nop
1:
or  sdCfg, 0x1<<29
nop
li a0,0xa1
bal ii2c_cfg
nop
2:
li  a1, 0x0
li  a0,0xa3
bal i2cread
nop
li  a1,0x0
beq v0,0xff,1f
nop
beq v0,0x80,1f
nop
move a0,v0
bal hexserial
nop
PRINTSTR ("\r\nNo DIMM in slot 1 \r\n");
b 2f
nop
1:
li a0,0xa3
bal ii2c_cfg
nop

b 2f
nop

2:
b 211f
nop
==

Ah, it talks about SLOT _1_ ! So, slot _0_ apparently read correctly  
but config info still not printed by pmon


Sorry, I misread output!

Re: [Qemu-devel] PMON2000 compilation and kernel question

[Andrew Randrianasulu]

> This could be some missing or buggy emulation. Maybe if you can get some 
> debug logs from kernel that could tell what it's doing. Usually at least -d 
> unimp,guest_errors options are recommended for debugging but if nothing is 
> printed then it's harder to find out what's causing the hang.

This was kernel dying in ata subsystem:

[1.34] io scheduler noop registered
[1.34] io scheduler deadline registered
[1.34] io scheduler cfq registered (default)
[1.352000] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[1.388000] console [ttyS0] disabled
[1.424000] serial8250.0: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) 
is a 16550A
[1.432000] console [ttyS0] enabled
[1.432000] console [ttyS0] enabled
[1.432000] bootconsole [early0] disabled
[1.432000] bootconsole [early0] disabled
[1.472000] scsi0 : pata_via
[1.476000] scsi1 : pata_via
[1.48] ata1: PATA max UDMA/100 cmd 0x4450 ctl 0x4460 bmdma 0x4440
[1.484000] ata2: PATA max UDMA/100 cmd 0x4458 ctl 0x4464 bmdma 0x4448
[1.524000] serio: i8042 KBD port at 0x60,0x64 irq 1
[1.524000] serio: i8042 AUX port at 0x60,0x64 irq 12
[1.532000] mousedev: PS/2 mouse device common for all mice
[1.552000] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[1.552000] rtc_cmos rtc_cmos: alarms up to one day, 114 bytes nvram
[1.556000] ledtrig-cpu: registered to indicate activity on CPUs
[1.556000] TCP: cubic registered
[1.56] NET: Registered protocol family 10
[1.588000] mip6: Mobile IPv6
[1.588000] NET: Registered protocol family 17
[1.588000] mpls_gso: MPLS GSO support
[1.596000] registered taskstats version 1
[1.612000] rtc_cmos rtc_cmos: setting system clock to 2019-03-06 15:48:12 
UTC (1551887292)
[1.684000] input: AT Raw Set 2 keyboard as 
/devices/platform/i8042/serio0/input/input0
[1.724000] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100
[1.724000] ata1.00: 204800 sectors, multi 16: LBA48
[1.728000] ata1.00: limited to UDMA/33 due to 40-wire cable
[1.736000] ata1.00: configured for UDMA/33
[1.796000] scsi 0:0:0:0: Direct-Access ATA  QEMU HARDDISK2.5+ 
PQ: 0 ANSI: 5
[1.82] sd 0:0:0:0: [sda] 204800 512-byte logical blocks: (104 MB/100 
MiB)
[1.832000] sd 0:0:0:0: [sda] Write Protect is off
[1.836000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[1.864000] Data bus error, epc == 804157d8, ra == 804f7ddc
[1.864000] Oops[#1]:

for 

mips64el-softmmu/qemu-system-mips64el -M fulong2e  -kernel 
/dev/shm/boot/vmlinux-3.16.0-4-loongson-2e -hda /dev/shm/LONGSOON_disk  -cdrom 
/dev/shm/debian-8.0.0-mipsel-xfce-CD-1.iso -nographic -d unimp,guest_errors 
-append "console=ttyS0" > VMLINUX_3.16.log 2>&1

and without ata disk but with just CD it moved into 'normal' panic (no root 
device)

[1.48] console [ttyS0] enabled
[1.48] console [ttyS0] enabled
[1.484000] bootconsole [early0] disabled
[1.484000] bootconsole [early0] disabled
[1.524000] scsi0 : pata_via
[1.528000] scsi1 : pata_via
[1.532000] ata1: PATA max UDMA/100 cmd 0x4450 ctl 0x4460 bmdma 0x4440
[1.536000] ata2: PATA max UDMA/100 cmd 0x4458 ctl 0x4464 bmdma 0x4448
[1.58] serio: i8042 KBD port at 0x60,0x64 irq 1
[1.584000] serio: i8042 AUX port at 0x60,0x64 irq 12
[1.596000] mousedev: PS/2 mouse device common for all mice
[1.616000] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[1.616000] rtc_cmos rtc_cmos: alarms up to one day, 114 bytes nvram
[1.62] ledtrig-cpu: registered to indicate activity on CPUs
[1.624000] TCP: cubic registered
[1.624000] NET: Registered protocol family 10
[1.648000] mip6: Mobile IPv6
[1.652000] NET: Registered protocol family 17
[1.652000] mpls_gso: MPLS GSO support
[1.656000] registered taskstats version 1
[1.688000] rtc_cmos rtc_cmos: setting system clock to 2019-03-06 15:50:38 
UTC (1551887438)
[1.752000] input: AT Raw Set 2 keyboard as 
/devices/platform/i8042/serio0/input/input0
[1.912000] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
[1.916000] ata2.00: limited to UDMA/33 due to 40-wire cable
[1.924000] ata2.00: configured for UDMA/33
[2.604000] input: ImExPS/2 Generic Explorer Mouse as 
/devices/platform/i8042/serio1/input/input2
[6.928000] ata2.00: qc timeout (cmd 0xa0)
[6.928000] ata2.00: TEST_UNIT_READY failed (err_mask=0x4)
[7.088000] ata2.00: configured for UDMA/33
[   12.092000] ata2.00: qc timeout (cmd 0xa0)
[   12.096000] ata2.00: TEST_UNIT_READY failed (err_mask=0x4)
[   12.096000] ata2.00: limiting speed to UDMA/33:PIO3
[   12.252000] ata2.00: configured for UDMA/33
[   17.252000] ata2.00: qc timeout (cmd 0xa0)
[   17.252000] ata2.00: TEST_UNIT_READY failed (err_mask=0x4)
[   17.256000] ata2.00: disabled
[   17.26] ata2: soft resetting link
[   17.42] ata2: EH complet

Re: [Qemu-devel] PMON2000 compilation and kernel question

[Andrew Randrianasulu]

> It is ati-vga specific not fulong2e specific and it's entirely possible (even 
> likely) that my minimal ati-vga emulation is not correct for 2d acceleration 
> yet but I've tested it with the pmon_2e.bin binary from the same place and it 
> worked with that. So if it does not work with the binary pmon for you then 
> that's not the same what I see or if it works with the binary but not with 
> the one compiled then either you're compiling another version that does 
> something differently or there's a difference in config. There are several 
> Bonito configs in pmon and the fulong2e might use another one or different 
> options. 


It worked fine with  binary pmon_2e.bin, and not for my self-compiled version. 
Still, I'm not sure about what kind of config they used, and at that commit.
In this sense newer pmon is more useful because it prints git commit and  build 
date.


Provided binary talks about pmon 1.1.2 (?) in top left corner.
I think one of my earlier self-compiled binaries behaved like this one
(printing a lot of pci info), but yes, something still not right  at my end
because for example DIMM size not detected correctly in my version.

But it gives prompt at serial console! :}

Will look at machine emulation in qemu, and try to configure pmon correctly. 

[Qemu-devel] [PATCH v3] PPC: E500: Add FSL I2C controller and integrate RTC with it

[Andrew Randrianasulu]

Original commit message:
This patch adds an emulation model for i2c controller found on most of the FSL 
SoCs.
It also integrates the RTC (ds1338) that sits on the i2c Bus with e500 machine 
model.

Patch was originally written by Amit Singh Tomar 
see http://patchwork.ozlabs.org/patch/431475/
I only fixed it enough for application on top of current qemu master
20b084c4b1401b7f8fbc385649d48c67b6f43d44, and hopefully fixed checkpatch errors

Tested by booting Linux kernel 4.20.12. Now e500 machine doesn't need 
network time protocol daemon because it will have working RTC 
(before all timestamps on files were from 2016)


Signed-off-by: Amit Singh Tomar 
Signed-off-by: Andrew Randrianasulu 
---

v1->v2: Expanded and fixed commit message

v2->v3: Changed Subject line back to original and From: field to 
my email address, moved my SoB line above first '---' and
added Tomar's Signed-off line back.

---
 default-configs/ppc-softmmu.mak |   2 +
 hw/i2c/Makefile.objs|   1 +
 hw/i2c/mpc_i2c.c| 357 
 hw/ppc/e500.c   |  54 ++
 4 files changed, 414 insertions(+)
 create mode 100644 hw/i2c/mpc_i2c.c

diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index 52acb7cf39..a560971f0c 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -8,6 +8,8 @@ include usb.mak
 CONFIG_PPC4XX=y
 CONFIG_M48T59=y
 CONFIG_SERIAL=y
+CONFIG_MPC_I2C=y
+CONFIG_DS1338=y
 CONFIG_I8257=y
 CONFIG_OPENPIC=y
 CONFIG_PPCE500_PCI=y
diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
index 9205cbee16..3eb584254f 100644
--- a/hw/i2c/Makefile.objs
+++ b/hw/i2c/Makefile.objs
@@ -9,5 +9,6 @@ common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
 common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
 common-obj-$(CONFIG_ASPEED_SOC) += aspeed_i2c.o
 common-obj-$(CONFIG_NRF51_SOC) += microbit_i2c.o
+common-obj-$(CONFIG_MPC_I2C) += mpc_i2c.o
 obj-$(CONFIG_OMAP) += omap_i2c.o
 obj-$(CONFIG_PPC4XX) += ppc4xx_i2c.o
diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
new file mode 100644
index 00..693ca7ef6b
--- /dev/null
+++ b/hw/i2c/mpc_i2c.c
@@ -0,0 +1,357 @@
+/*
+ * Copyright (C) 2014 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Amit Tomar, 
+ *
+ * Description:
+ * This file is derived from IMX I2C controller,
+ * by Jean-Christophe DUBOIS .
+ *
+ * Thanks to Scott Wood and Alexander Graf for their kind help on this.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2 or later,
+ * as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/i2c/i2c.h"
+#include "qemu/log.h"
+#include "hw/sysbus.h"
+
+/* #define DEBUG_I2C */
+
+#ifdef DEBUG_I2C
+#define DPRINTF(fmt, ...)  \
+do { fprintf(stderr, "mpc_i2c[%s]: " fmt, __func__, ## __VA_ARGS__); \
+} while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+#define TYPE_MPC_I2C "mpc-i2c"
+#define MPC_I2C(obj) \
+OBJECT_CHECK(MPCI2CState, (obj), TYPE_MPC_I2C)
+
+#define MPC_I2C_ADR   0x00
+#define MPC_I2C_FDR   0x04
+#define MPC_I2C_CR0x08
+#define MPC_I2C_SR0x0c
+#define MPC_I2C_DR0x10
+#define MPC_I2C_DFSRR 0x14
+
+#define CCR_MEN  (1 << 7)
+#define CCR_MIEN (1 << 6)
+#define CCR_MSTA (1 << 5)
+#define CCR_MTX  (1 << 4)
+#define CCR_TXAK (1 << 3)
+#define CCR_RSTA (1 << 2)
+#define CCR_BCST (1 << 0)
+
+#define CSR_MCF  (1 << 7)
+#define CSR_MAAS (1 << 6)
+#define CSR_MBB  (1 << 5)
+#define CSR_MAL  (1 << 4)
+#define CSR_SRW  (1 << 2)
+#define CSR_MIF  (1 << 1)
+#define CSR_RXAK (1 << 0)
+
+#define CADR_MASK 0xFE
+#define CFDR_MASK 0x3F
+#define CCR_MASK  0xFC
+#define CSR_MASK  0xED
+#define CDR_MASK  0xFF
+
+#define CYCLE_RESET 0xFF
+
+typedef struct MPCI2CState {
+SysBusDevice parent_obj;
+
+I2CBus *bus;
+qemu_irq irq;
+MemoryRegion iomem;
+
+uint8_t address;
+uint8_t adr;
+uint8_t fdr;
+uint8_t cr;
+uint8_t sr;
+uint8_t dr;
+uint8_t dfssr;
+} MPCI2CState;
+
+static bool mpc_i2c_is_enabled(MPCI2CState *s)
+{
+return s->cr & CCR_MEN;
+}
+
+static bool mpc_i2c_is_master(MPCI2CState *s)
+{
+return s->cr & CCR_MSTA;
+}
+
+static bool mpc_i2c_direction_is_tx(MPCI2CState *s)
+{
+return s->cr & CCR_MTX;
+}
+
+static bool mpc_i2c_irq_pending(MPCI2CState *s)
+{
+return s->sr & CSR_MIF;
+}
+
+static bool mpc_i2c_irq_is_enabled(MPCI2CState *s)
+{
+return s->cr & CCR_MIEN;
+}
+
+static void mpc_i2c_reset(DeviceState *dev)
+{
+MPCI2CState *i2c = MPC_I2C(dev);
+
+ 

[Qemu-devel] PMON2000 compilation and kernel question

[Andrew Randrianasulu]

Hello, all.

I was compiling those pmons for last two days, and I happy to say most of my 
hackery was
unnecessary.

Just unpack pmon_1c.tar.gz and toolchain-pmon.tar.bz2
compile tools in pmon/tools (just make), create  directory /opt/pmon2000/tools, 
install tools,
be sure /opt/pmon2000/tools/bin in your $PATH, put compiler in /usr/local/comp, 
put build.sh 
script from unpacked toolchain tree into pmon.zloader dir, reset tree (git 
checkout -b label) 
to some known or desired commit

few of them I tested:

9048810a267835e8efb0496fd99884bd500c43a0

17471780223332a7016959bcb9784ba249bd8660

dd26466da98371470af957993a600719466305f9

for last one you probably want to revert "move highmemcpy highset into lib.",
because it was breaking zloader.2edev compilation for me.

Now, most of my hacks were unnecessary, you can just use this Bonito file
in Targets/Bonito2edev/conf/:

==
# $Id: Bonito,v 1.1.1.1 2006/09/14 01:59:09 root Exp $ # #  GENERIC 
configuration for Galileo EV64240 # #  This file is supposed to be included by 
target file after #  endian has been defined.
#
machine Bonito2edevmips# CPU Architecture, Platform
config  pmon

#
#  Define target endian
#
makeoptions ENDIAN=EL   # Little endian version.


#include "conf/GENERIC_ALL"

#
# System Name and Target Name
#
option  SYSTYPE="\"Bonito\""
option  TARGETNAME="\"Bonito\""

#
# Platform options
#
option  BONITOEL
option  DEVBD2E
option  MIPS
option  INET

select  mod_flash_amd   # AMD flash device programming
select  mod_flash_intel # intel flash device programming
select  mod_flash_sst   # intel flash device programming
select  mod_debugger# Debugging module
select  mod_symbols # Symbol table handling
select  mod_s3load  # Srecord loading
#select mod_fastload# LSI Fastload
select  mod_elfload # ELF loading

#
# Command selection. Selects pmon commands
#
select  cmd_newmt
select  cmd_setup
select  mod_display
select  cmd_about   # Display info about PMON
select  cmd_boot# Boot wrapper
select  cmd_mycmd
select  cmd_xmodem
select  ramfiles
select  cmd_newmt
select  cmd_cache   # Cache enabling
#select cmd_call# Call a function command
select  cmd_date# Time of day command
select  cmd_env # Full blown environment command set
select  cmd_flash   # Flash programming cmds
select  cmd_hist# Command history
select  cmd_ifaddr  # Interface address command
select  cmd_l   # Disassemble
select  cmd_mem # Memory manipulation commands
select  cmd_more# More paginator
select  cmd_mt  # Simple memory test command
select  cmd_misc# Reboot & Flush etc.
#select cmd_stty# TTY setings command
select  cmd_tr  # Host port-through command
select  cmd_devls   # Device list
select  cmd_set # As cmd_env but not req. cmd_hist
select  cmd_testdisk
select  cmd_test
select  pmon_zmodem_rz
#
select  cmd_shell   # Shell commands, vers, help, eval
#
#
# Platform options
#
select  mod_uart_ns16550# Standard UART driver
#option CONS_BAUD=B9600
option  CONS_BAUD=B115200
select  ext2
select  fatfs
#select mod_x86emu  # X86 emulation for VGA
option  MY40IO
#select mod_x86emu_int10
select  mod_vgacon
select  mod_framebuffer
option  X640x480
option  CONFIG_VIDEO_16BPP
option  NOPCINAMES  # Save some space for x86emu
#option FASTBOOT
select  vt82c686#via686a/b code

#
# Functional options.
#
option  NOSNOOP # Caches are no-snooping

#
# HAVE options. What tgt level provide
#
option  HAVE_TOD# Time-Of-Day clock
option  HAVE_NVENV  #  Platform has non-volatile env mem
option  HAVE_LOGO   # Output splash logo
option  USE_SUPERIO_UART
#option USE_LEGACY_RTC
#option GODSONEV2A
#option LINUX_PC
#option LONGMENG
option  RADEON7000
#option DEBUG_EMU_VGA
option  AUTOLOAD
#option CONFIG_PCI0_LARGE_MEM
#option CONFIG_PCI0_HUGE_MEM
#option CONFIG_PCI0_GAINT_MEM
option  CONFIG_CACHE_64K_4WAY
option  NVRAM_IN_FLASH

#
#  Now the Machine specification
#
mainbus0at root
localbus0   at mainbus0
#fd0 at mainbu

Re: [Qemu-devel] [PATCH v2 0/3] Misc MIPS fulong2e improvements

[Andrew Randrianasulu]

Actually compiled something!

root@slax:/dev/shm/pmon/zloader.2edev# qemu-system-mips64el -M fulong2e -cpu 
Loongson-2E -m 1G  -bios pmon.bin -nographic

PMON2000 MIPS Initializing. Standby...
ERRORPC= CONFIG=00030932
 PRID=6302
DIMM read
read memory type
read number of rows
read blocks per ddrram
read number of sides
read width
0002
No DIMM in slot 1
DIMM SIZE=1000
dma: command ae not supported
sdcfg=2d9043ae
msize=1000
Init SDRAM Done!
Sizing caches...
Init caches...
godson2 caches found
Init caches done, cfg = 00030932

Copy PMON to execute location...
  start = 0x8100
  s0 = 0x3ec0
a105
copy text section done.
Copy PMON to execute location done.
sp=80ffc000Uncompressing BiosOK,Booting Bios
FREQ
FREI
DONE
DEVI
ENVI
MAPV
in envinit
nvram=bfc0
unknow flash type
unknow flash type
Mfg  0, Id 60
NVRAM is invalid!
NVRAM@bfc0
STDV
8010:  memory between 82fff400-8300  is already been allocated,heap is 
already above this point
SBDD
686I
0x3f8=ff
P12PCIH
PCIS
PCIR
PCIW
NETI
RTCL
PCID
VGAI
No VGA PCI device available
in configure
mainbus0 (root)
localbus0 at mainbus0
pcibr0 at mainbus0
pci0 at pcibr0 bus 0
vendor/product: 0x1106/0x0686 (bridge, ISA) at pci0 dev 5 function 0 not 
configured
pciide0 at pci0 dev 5 function 1 vendor/product: 0x1106/0x0571 (mass storage, 
IDE): DMA (unsupported), ch 0 cfg to compat, ch 1 cfg to compat
cd0 at pciide0 channel 1cd attach drive=0
dv_xname cd0
vendor/product: 0x1106/0x3038 (serialbus, USB) at pci0 dev 5 function 2 not 
configured
vendor/product: 0x1106/0x3038 (serialbus, USB) at pci0 dev 5 function 3 not 
configured
vendor/product: 0x1106/0x3057 (bridge, miscellaneous) at pci0 dev 5 function 4 
not configured
vendor/product: 0x1106/0x3058 (multimedia, audio) at pci0 dev 5 function 5 not 
configured
vendor/product: 0x1106/0x3068 (communications, miscellaneous) at pci0 dev 5 
function 6 not configured
rtl0 at pci0 dev 7 function 0 vendor/product: 0x10ec/0x8139 (network, 
ethernet)8139 iobase =bfd04000
: generic poll, address 00:00:00:00:00:00
Config1
 100Mbps HALF-DUPLEX.
in if attach
out configure
Keyboard succesfully initialized.
devconfig done.
ifinit done.
domaininit done.
init_proc
HSTI
SYMI
SBDE

Configuration [Bonito,EL,NET,IDE]
Version: PMON2000 2.1 (Bonito) #1: Вт мар  5 00:02:06 MSK 2019 commit 
b6ef3b0253f1ba9be62d01b07f9900d16c66e38e Author: QiaoChong 
 Date:   Tue Dec 28 09:59:01 2010 +0800 .
Supported loaders [srec, elf, bin]
Supported filesystems [net, fat, fs, disk, iso9660, socket, tty, ram]
This software may be redistributed under the BSD copyright.
Copyright 2000-2002, Opsycon AB, Sweden.
Copyright 2005, ICT CAS.
CPU GODSON2 @ 199.94 MHz / Bus @ 66.00 MHz
Memory size 256 MB (256 MB Low memory,   0 MB High memory) .
Primary Instruction cache size 64kb (32 line, 4 way)
Primary Data cache size 64kb (32 line, 4 way)
Secondary cache size 512kb

BEV1
BEV0
BEV in SR set to zero.
PMON> ls
Pmon_ftext  etext   start
PMON> help
help: Command not found. Try 'h' for help!
PMON> h
 Boot and Load
boot  boot  
 oload  load memory from hostport
load  load file
MyCmds
 testnet  testnet rtl0 [recv|send|loop] 
  cp0s  access cp0
 pcs  select pci dev function   
 disks  select disk
  d1  dump address byte 
d2  dump address half world
  d4  dump address world
d8  dump address double word
  m1  modify address byte   
m2  mofify address half world
  m4  modify address world  
m8  modify address double word
  setvga  set vga_available 
setkbd  set kbd_available
setinput  set input_from_both   
 setoutput  set output_to_both
 initkbd  kbd_initialize
 cache  cache [0 1]
loop  loopcmd count cmd...  
  Loop  loopcmd count cmd...
 testide  test ide dma  
  checksum  calculate checksum for a memory section
   fdisk  dump disk partation   
  ifconfig  ifconig fx0 [up|down|remove|stat|setmac|readrom|setrom|addr 
[netmask]
ifup  ifup fxp0 
ifdown  ifdown fxp0
  rtlist  rtlist

Re: [Qemu-devel] [PATCH v2 0/3] Misc MIPS fulong2e improvements

[Andrew Randrianasulu]

Unfortunately, even after unpacking pmon_1c.tar.gz , compiling and installing 
tools into /opt/pmon200o/tools  resetting resulted git inside 'pmon' directory 
to earlist commit possible (because modern pmon fails to comple 2e targets), 
unpacking and copying to /usr/local toolchain based on gcc 2.95.3, and adding 
build.sh script to specific directory pmon/zloader - I was only able to build 
gzrom elf:



/dev/shm/pmon/zloader.2emini# qemu-system-mips64el -M fulong2e -cpu Loongson-2E 
-m 256  -kernel gzrom -nographic

PMON2000 MIPS Initializing. Standby...
ERRORPC= CONFIG=00030932
 PRID=6302
DIMM read
read memory type
read number of rows
read blocks per ddrram
read number of sides
read width
0020
No DIMM in slot 1
DIMM SIZE=0800
dma: command ae not supported
sdcfg=2d9043ae
msize=0800
Init SDRAM Done!
Sizing caches...
Init caches...
godson2 caches found
Init caches done, cfg = 00030932

Copy PMON to execute location...
  start = 0x8100
  s0 = 0x2000
000d
copy text section done.
Copy PMON to execute location done.
sp=80ffc000Uncompressing Bios..OK,Booting Bios
QEMU 3.0.50 monitor - type 'help' for more information
(qemu) quit

this is without you patch series  and with quite oldish qemu (3.1 rc)

Re: [Qemu-devel] [PATCH v2 0/3] Misc MIPS fulong2e improvements

[Andrew Randrianasulu]

Hi, Zoltan!

I think I found some sources for pmon:

http://www.anheng.com.cn/loongson/pmon/updates.lemote.com/files/upload/lm/firmware/pmon/source/pmon-priv.tar.gz

slooowly downloading (20507323 (20M))

and then in upper dir

http://www.anheng.com.cn/loongson/pmon/

toolchain-pmon.tar.bz2  2010-08-31 09:2736M  

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2] Re-applying Freescale PPC E500 i2c/RTC patch

[Andrew Randrianasulu]

В сообщении от Monday 04 March 2019 05:51:27 BALATON Zoltan написал(а):
> On Mon, 4 Mar 2019, Andrew Randrianasulu wrote:
> > From: Amit Singh Tomar 
> >
> > Original commit message:
> > This patch adds an emulation model for i2c controller found on most of the 
> > FSL SoCs.
> > It also integrates the RTC (ds1338) that sits on the i2c Bus with e500 
> > machine model.
> >
> > Patch was originally written by Amit Singh Tomar 
> > see http://patchwork.ozlabs.org/patch/431475/
> > I only fixed it enough for application on top of current qemu master
> > 20b084c4b1401b7f8fbc385649d48c67b6f43d44, and hopefully fixed checkpatch 
> > errors
> >
> > Tested by booting Linux kernel 4.20.12. Now e500 machine doesn't need
> > network time protocol daemon because it will have working RTC
> > (before all timestamps on files were from 2016)
> >
> > ---
> >
> > v1->v2: Expanded and fixed commit message
> >
> >
> > Signed-off-by: Andrew Randrianasulu 
> > ---
> 
> Almost... Patch now applies but subject and commit message are not yet 
> right. Look at existing commit messages for examples how it should look 
> (e.g. git log hw/ppc/e500.c). The email subject will become commit title, 
> this should start with something showing which part you change like e500:. 
> Then one line summary of what the patch is doing. You can probably keep 
> original title, no need to say re-applying or things like that there. You 
> can explain this in patch body. The text up to the first --- will be the 
> body of the commit message so you should describe in more detail what the 
> patch does here. Also this should include all Signed-off-by and other 
> tags at the end before the ---.
> 
> Everything after --- are additional comments that won't be included in the 
> commit message so you can put version history or any other remarks there 
> that should not be kept after applying the patch.
> 
> This patch is missing Signed-off-by of the original author and has yours 
> below --- that's why checkpatch complains. You should keep the the 
> original Signed-off-by even if you add From: of the original author. I 
> think you may not include From: since you're not forwarding a patch 
> unchanged but this is now your patch based on the original since you've 
> changed it so it can have your From: address from email header and 
> Signed-off-by of both original author and yours to show where it came from 
> originally. You can also mention this in commit message to make it clear.
> 
> Or you can keep From of original author and explain in commit message what 
> you've changed but it still needs both Signed-off-by lines even then.
> 
> Hopefully this makes sense. This should already be explained in the 
> SubmitAPatch wiki page but that can be complicated at first.

Thanks for explaining all this.
Right now top of my patch looks like this:

From ad2b4baf8b369c8ef354e56f75ae780413acd989 Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu 
Date: Sun, 3 Mar 2019 00:05:04 +0300
Subject: [PATCH v3] PPC: E500: Add FSL I2C controller and integrate RTC with it

Original commit message:
This patch adds an emulation model for i2c controller found on most of the FSL 
SoCs.
It also integrates the RTC (ds1338) that sits on the i2c Bus with e500 machine 
model.

Patch was originally written by Amit Singh Tomar 
see http://patchwork.ozlabs.org/patch/431475/
I only fixed it enough for application on top of current qemu master
20b084c4b1401b7f8fbc385649d48c67b6f43d44, and hopefully fixed checkpatch errors

Tested by booting Linux kernel 4.20.12. Now e500 machine doesn't need.
network time protocol daemon because it will have working RTC.
(before all timestamps on files were from 2016)


Signed-off-by: Amit Singh Tomar 
Signed-off-by: Andrew Randrianasulu 
---

v1->v2: Expanded and fixed commit message

v2->v3: Changed Subject line back to original and From: field to.
my email address, moved my SoB line above first '---' and
added Tomar's Signed-off line back.

---

is it OK ok to send? (assuming it applies, compiles and boots, I test this now
with git am, make and launching qemu with -kernel option.)


> 
> Regards,
> BALATON Zoltan
> 
> > default-configs/ppc-softmmu.mak |   2 +
> > hw/i2c/Makefile.objs|   1 +
> > hw/i2c/mpc_i2c.c| 357 
> > 
> > hw/ppc/e500.c   |  54 ++
> > 4 files changed, 414 insertions(+)
> > create mode 100644 hw/i2c/mpc_i2c.c
> >
> > diff --git a/default-configs/ppc-softmmu.mak 
> > b/default-configs/ppc-softmmu.mak
> > index 52acb7cf39..a560971f0c 100644
> > --- a/default-c

[Qemu-devel] [PATCH v2] Re-applying Freescale PPC E500 i2c/RTC patch

[Andrew Randrianasulu]

From: Amit Singh Tomar 

Original commit message:
This patch adds an emulation model for i2c controller found on most of the FSL 
SoCs.
It also integrates the RTC (ds1338) that sits on the i2c Bus with e500 machine 
model.

Patch was originally written by Amit Singh Tomar 
see http://patchwork.ozlabs.org/patch/431475/
I only fixed it enough for application on top of current qemu master
20b084c4b1401b7f8fbc385649d48c67b6f43d44, and hopefully fixed checkpatch errors

Tested by booting Linux kernel 4.20.12. Now e500 machine doesn't need 
network time protocol daemon because it will have working RTC 
(before all timestamps on files were from 2016)

---

v1->v2: Expanded and fixed commit message


Signed-off-by: Andrew Randrianasulu 
---
 default-configs/ppc-softmmu.mak |   2 +
 hw/i2c/Makefile.objs|   1 +
 hw/i2c/mpc_i2c.c| 357 
 hw/ppc/e500.c   |  54 ++
 4 files changed, 414 insertions(+)
 create mode 100644 hw/i2c/mpc_i2c.c

diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index 52acb7cf39..a560971f0c 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -8,6 +8,8 @@ include usb.mak
 CONFIG_PPC4XX=y
 CONFIG_M48T59=y
 CONFIG_SERIAL=y
+CONFIG_MPC_I2C=y
+CONFIG_DS1338=y
 CONFIG_I8257=y
 CONFIG_OPENPIC=y
 CONFIG_PPCE500_PCI=y
diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
index 9205cbee16..3eb584254f 100644
--- a/hw/i2c/Makefile.objs
+++ b/hw/i2c/Makefile.objs
@@ -9,5 +9,6 @@ common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
 common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
 common-obj-$(CONFIG_ASPEED_SOC) += aspeed_i2c.o
 common-obj-$(CONFIG_NRF51_SOC) += microbit_i2c.o
+common-obj-$(CONFIG_MPC_I2C) += mpc_i2c.o
 obj-$(CONFIG_OMAP) += omap_i2c.o
 obj-$(CONFIG_PPC4XX) += ppc4xx_i2c.o
diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
new file mode 100644
index 00..693ca7ef6b
--- /dev/null
+++ b/hw/i2c/mpc_i2c.c
@@ -0,0 +1,357 @@
+/*
+ * Copyright (C) 2014 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Amit Tomar, 
+ *
+ * Description:
+ * This file is derived from IMX I2C controller,
+ * by Jean-Christophe DUBOIS .
+ *
+ * Thanks to Scott Wood and Alexander Graf for their kind help on this.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2 or later,
+ * as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/i2c/i2c.h"
+#include "qemu/log.h"
+#include "hw/sysbus.h"
+
+/* #define DEBUG_I2C */
+
+#ifdef DEBUG_I2C
+#define DPRINTF(fmt, ...)  \
+do { fprintf(stderr, "mpc_i2c[%s]: " fmt, __func__, ## __VA_ARGS__); \
+} while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+#define TYPE_MPC_I2C "mpc-i2c"
+#define MPC_I2C(obj) \
+OBJECT_CHECK(MPCI2CState, (obj), TYPE_MPC_I2C)
+
+#define MPC_I2C_ADR   0x00
+#define MPC_I2C_FDR   0x04
+#define MPC_I2C_CR0x08
+#define MPC_I2C_SR0x0c
+#define MPC_I2C_DR0x10
+#define MPC_I2C_DFSRR 0x14
+
+#define CCR_MEN  (1 << 7)
+#define CCR_MIEN (1 << 6)
+#define CCR_MSTA (1 << 5)
+#define CCR_MTX  (1 << 4)
+#define CCR_TXAK (1 << 3)
+#define CCR_RSTA (1 << 2)
+#define CCR_BCST (1 << 0)
+
+#define CSR_MCF  (1 << 7)
+#define CSR_MAAS (1 << 6)
+#define CSR_MBB  (1 << 5)
+#define CSR_MAL  (1 << 4)
+#define CSR_SRW  (1 << 2)
+#define CSR_MIF  (1 << 1)
+#define CSR_RXAK (1 << 0)
+
+#define CADR_MASK 0xFE
+#define CFDR_MASK 0x3F
+#define CCR_MASK  0xFC
+#define CSR_MASK  0xED
+#define CDR_MASK  0xFF
+
+#define CYCLE_RESET 0xFF
+
+typedef struct MPCI2CState {
+SysBusDevice parent_obj;
+
+I2CBus *bus;
+qemu_irq irq;
+MemoryRegion iomem;
+
+uint8_t address;
+uint8_t adr;
+uint8_t fdr;
+uint8_t cr;
+uint8_t sr;
+uint8_t dr;
+uint8_t dfssr;
+} MPCI2CState;
+
+static bool mpc_i2c_is_enabled(MPCI2CState *s)
+{
+return s->cr & CCR_MEN;
+}
+
+static bool mpc_i2c_is_master(MPCI2CState *s)
+{
+return s->cr & CCR_MSTA;
+}
+
+static bool mpc_i2c_direction_is_tx(MPCI2CState *s)
+{
+return s->cr & CCR_MTX;
+}
+
+static bool mpc_i2c_irq_pending(MPCI2CState *s)
+{
+return s->sr & CSR_MIF;
+}
+
+static bool mpc_i2c_irq_is_enabled(MPCI2CState *s)
+{
+return s->cr & CCR_MIEN;
+}
+
+static void mpc_i2c_reset(DeviceState *dev)
+{
+MPCI2CState *i2c = MPC_I2C(dev);
+
+i2c->address = 0xFF;
+i2c->adr = 0x00;
+i2c->fdr = 0x00;
+i2c->cr =  0x00;
+i2c->sr =  0x81;
+i2c->dr =  0x00;
+}
+
+static void mpc_i2c_irq(MPCI

Re: [Qemu-devel] [PATCH] Re-applying Freescale PPC E500 i2c/RTC patch

[Andrew Randrianasulu]

В сообщении от Monday 04 March 2019 02:57:28 David Gibson написал(а):
> On Sun, Mar 03, 2019 at 12:21:21AM +0300, Andrew Randrianasulu wrote:
> > From ad2b4baf8b369c8ef354e56f75ae780413acd989 Mon Sep 17 00:00:00 2001
> > From: Amit Singh Tomar 
> > Date: Sun, 3 Mar 2019 00:05:04 +0300
> > Subject: [PATCH] Re-applying Freescale PPC E500 i2c/RTC patch
> > 
> > Patch was originally writen by Amit Singh Tomar 
> > see http://patchwork.ozlabs.org/patch/431475/
> > I only fixed it enough for application on top of current qemu master
> > 20b084c4b1401b7f8fbc385649d48c67b6f43d44, and hopefully fixed
> > checkpatch errors
> 
> So.. that tells me some of the patch's history, but doesn't mention
> what the patch actually does and why it's a good thing to have, which
> are the most important things to go in the commit message.

Then I should add original commit message, i think?

---
This patch adds an emulation model for i2c controller found on most of the FSL 
SoCs.
It also integrates the RTC (ds1338) that sits on the i2c Bus with e500 machine 
model.


I hopefully set up git-send-email this time, so will try to send v2 with fixed 
commit message.


> 
> > 
> > Tested by booting Linux kernel 4.20.12.
> > 
> > Signed-off-by: Andrew Randrianasulu 
> > ---
> >  default-configs/ppc-softmmu.mak |   2 +
> >  hw/i2c/Makefile.objs|   1 +
> >  hw/i2c/mpc_i2c.c| 357 
> > 
> >  hw/ppc/e500.c   |  54 ++
> >  4 files changed, 414 insertions(+)
> >  create mode 100644 hw/i2c/mpc_i2c.c
> > 
> > diff --git a/default-configs/ppc-softmmu.mak 
> > b/default-configs/ppc-softmmu.mak
> > index 52acb7cf39..a560971f0c 100644
> > --- a/default-configs/ppc-softmmu.mak
> > +++ b/default-configs/ppc-softmmu.mak
> > @@ -8,6 +8,8 @@ include usb.mak
> >  CONFIG_PPC4XX=y
> >  CONFIG_M48T59=y
> >  CONFIG_SERIAL=y
> > +CONFIG_MPC_I2C=y
> > +CONFIG_DS1338=y
> >  CONFIG_I8257=y
> >  CONFIG_OPENPIC=y
> >  CONFIG_PPCE500_PCI=y
> > diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
> > index 9205cbee16..3eb584254f 100644
> > --- a/hw/i2c/Makefile.objs
> > +++ b/hw/i2c/Makefile.objs
> > @@ -9,5 +9,6 @@ common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
> >  common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
> >  common-obj-$(CONFIG_ASPEED_SOC) += aspeed_i2c.o
> >  common-obj-$(CONFIG_NRF51_SOC) += microbit_i2c.o
> > +common-obj-$(CONFIG_MPC_I2C) += mpc_i2c.o
> >  obj-$(CONFIG_OMAP) += omap_i2c.o
> >  obj-$(CONFIG_PPC4XX) += ppc4xx_i2c.o
> > diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
> > new file mode 100644
> > index 00..693ca7ef6b
> > --- /dev/null
> > +++ b/hw/i2c/mpc_i2c.c
> > @@ -0,0 +1,357 @@
> > +/*
> > + * Copyright (C) 2014 Freescale Semiconductor, Inc. All rights reserved.
> > + *
> > + * Author: Amit Tomar, 
> > + *
> > + * Description:
> > + * This file is derived from IMX I2C controller,
> > + * by Jean-Christophe DUBOIS .
> > + *
> > + * Thanks to Scott Wood and Alexander Graf for their kind help on this.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License, version 2 or 
> > later,
> > + * as published by the Free Software Foundation.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with this library; if not, see 
> > <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include "hw/i2c/i2c.h"
> > +#include "qemu/log.h"
> > +#include "hw/sysbus.h"
> > +
> > +/* #define DEBUG_I2C */
> > +
> > +#ifdef DEBUG_I2C
> > +#define DPRINTF(fmt, ...)  \
> > +do { fprintf(stderr, "mpc_i2c[%s]: " fmt, __func__, ## __VA_ARGS__); \
> > +} while (0)
> > +#else
> > +#define DPRINTF(fmt, ...) do {} while (0)
> > +#endif
> > +
> > +#define TYPE_MPC_I2C "mpc-i2c"
> > +#define MPC_I2C(obj) \
> > +OBJECT_CHECK(MPCI2CState, (obj), TYPE_MPC_I2C)
> > +
> > +#define MPC_I2C_ADR   0x00
> > +#define MPC_I2C_FDR   0x04
> > +#define MPC_I2C_CR0x08
> > +#define MPC_I2C_SR0x0c
> > +#define MPC_I2C_DR0x10
> > +#define MPC_I2C_DFSRR 0x14
> > +
> > +#define CCR_MEN  (1 << 7)
> > +#define CCR_MIEN (1 << 6)
> > +#define CCR_MSTA (1 &l

Re: [Qemu-devel] [Qemu-ppc] Forward-porting RTC device for eppc500 ?

[Andrew Randrianasulu]

В сообщении от Sunday 03 March 2019 03:17:47 BALATON Zoltan написал(а):
> On Sun, 3 Mar 2019, Andrew Randrianasulu wrote:
> > git commit -a --author="Amit Singh Tomar "
> > git format-patch -s 20b084c4b1401b7f8fbc385649d48c67b6f43d44
> >
> > scripts/checkpatch.pl
> > 0001-Re-applying-Freescale-PPC-E500-i2c-RTC-patch.patch
> >
> > After this I created new message in Kmail and inserted 0001 file, edited
> > it a bit more (adding patchwork link and mentioning fact I actually
> > boot-tested patch), and then send out.
>
> When sending patches to list make sure your mailer sends them as plain
> text and does not try to break up lines or alter white space because that
> breaks the patch and it won't apply with git am. You can check it in
> patchew (linked from SubmitAPatch wiki page):
>
> https://patchew.org/QEMU/201903030021.22070.randrianas...@gmail.com/
>
> Not sure if Kmail can do this, maybe it has some settings for this but
> it's usually better to do all editing on the git commit and send patch
> mails with git send-email.

I see, it failed to apply. Will try to convince git send-mail to work (last 
time 
it failed for me, but it was long time ago)

>
> > Guess next time I better to add second "-s" to git format-patch, so first
> > signed-off-by-line from original will be around too?
> >
> > Or ..lets wait what actual maintainers will say.
>
> Yes, I'll let actual maintainers to comment then you can do a corrected
> version with any requested fixes or Reviewed-by tags added. I think for
> next revision you should leave original author's Signed-off-by in commit
> message and add yours with -s after that. (When sending another version of
> a patch use -v2 option of git format-patch to add v2 to the patch
> subject and so on for higher revisions if needed.)

Thanks.


>
> Regards,
> BALATON Zoltan

Re: [Qemu-devel] [Qemu-ppc] Forward-porting RTC device for eppc500 ?

[Andrew Randrianasulu]

В сообщении от Saturday 02 March 2019 23:40:47 BALATON Zoltan написал(а):

[snip]


>
> On Sat, 2 Mar 2019, Andrew Randrianasulu wrote:
> > Should I fix those?
>
> [...]
>
> > total: 14 errors, 2 warnings, 462 lines checked
> >
> > 0001-Re-applying-of-Freescale-PPC500-i2c-RTC-patch-writte.patch has style
> > problems, please review.  If any of these errors
> > are false positives report them to the maintainer, see
> > CHECKPATCH in MAINTAINERS.
>
> Yes, patches submitted to the list should pass checkpatch otherwise they
> will be rejected by automated build tests. These are simple to fix, just
> add spaces as checkpatch suggests: (1 << 0) and so on.
>
> (It's better to keep the list cc-d on reply so others can also answer your
> questions or correct my answers if I missed something which is not
> possible if you reply to me off list.)


Posted to list, arrived as 
https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg00413.html

I used (in specifically created branch)

git reset origin
git reset --hard
git apply \
/home/guest/botva/src/src/qemu/0001-Re-applying-Freescale-PPC500-i2c-RTC-patch-written-b.patch
rm hw/i2c/mpc_i2c.c (leftover from my previous attempt at commiting)
again

git apply \
/home/guest/botva/src/src/qemu/0001-Re-applying-Freescale-PPC500-i2c-RTC-patch-written-b.patch
{now it applies cleanly)

git add hw/i2c/mpc_i2c.c

make

ppc64-softmmu/qemu-system-ppc64 -M ppce500 -cpu 
e5500 -kernel 
/mnt/sdb1/PPC-img/linux-image-4.20.12-X1000_X5000/X5000_and_QEMU_e5500/uImage-4.20
 -nographic

git commit -a --author="Amit Singh Tomar "  
git format-patch -s 20b084c4b1401b7f8fbc385649d48c67b6f43d44
scripts/checkpatch.pl 0001-Re-applying-Freescale-PPC-E500-i2c-RTC-patch.patch

After this I created new message in Kmail and inserted 0001 file, edited it a 
bit more (adding patchwork link and mentioning fact I actually boot-tested 
patch), and then send out.

Guess next time I better to add second "-s" to git format-patch, so first 
signed-off-by-line from original will be around too?

Or ..lets wait what actual maintainers will say. 
>
> Regards,
> BALATON Zoltan

[Qemu-devel] [PATCH] Re-applying Freescale PPC E500 i2c/RTC patch

[Andrew Randrianasulu]

From ad2b4baf8b369c8ef354e56f75ae780413acd989 Mon Sep 17 00:00:00 2001
From: Amit Singh Tomar 
Date: Sun, 3 Mar 2019 00:05:04 +0300
Subject: [PATCH] Re-applying Freescale PPC E500 i2c/RTC patch

Patch was originally writen by Amit Singh Tomar 
see http://patchwork.ozlabs.org/patch/431475/
I only fixed it enough for application on top of current qemu master
20b084c4b1401b7f8fbc385649d48c67b6f43d44, and hopefully fixed checkpatch errors

Tested by booting Linux kernel 4.20.12.

Signed-off-by: Andrew Randrianasulu 
---
 default-configs/ppc-softmmu.mak |   2 +
 hw/i2c/Makefile.objs|   1 +
 hw/i2c/mpc_i2c.c| 357 
 hw/ppc/e500.c   |  54 ++
 4 files changed, 414 insertions(+)
 create mode 100644 hw/i2c/mpc_i2c.c

diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index 52acb7cf39..a560971f0c 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -8,6 +8,8 @@ include usb.mak
 CONFIG_PPC4XX=y
 CONFIG_M48T59=y
 CONFIG_SERIAL=y
+CONFIG_MPC_I2C=y
+CONFIG_DS1338=y
 CONFIG_I8257=y
 CONFIG_OPENPIC=y
 CONFIG_PPCE500_PCI=y
diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
index 9205cbee16..3eb584254f 100644
--- a/hw/i2c/Makefile.objs
+++ b/hw/i2c/Makefile.objs
@@ -9,5 +9,6 @@ common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
 common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
 common-obj-$(CONFIG_ASPEED_SOC) += aspeed_i2c.o
 common-obj-$(CONFIG_NRF51_SOC) += microbit_i2c.o
+common-obj-$(CONFIG_MPC_I2C) += mpc_i2c.o
 obj-$(CONFIG_OMAP) += omap_i2c.o
 obj-$(CONFIG_PPC4XX) += ppc4xx_i2c.o
diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
new file mode 100644
index 00..693ca7ef6b
--- /dev/null
+++ b/hw/i2c/mpc_i2c.c
@@ -0,0 +1,357 @@
+/*
+ * Copyright (C) 2014 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Amit Tomar, 
+ *
+ * Description:
+ * This file is derived from IMX I2C controller,
+ * by Jean-Christophe DUBOIS .
+ *
+ * Thanks to Scott Wood and Alexander Graf for their kind help on this.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2 or later,
+ * as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/i2c/i2c.h"
+#include "qemu/log.h"
+#include "hw/sysbus.h"
+
+/* #define DEBUG_I2C */
+
+#ifdef DEBUG_I2C
+#define DPRINTF(fmt, ...)  \
+do { fprintf(stderr, "mpc_i2c[%s]: " fmt, __func__, ## __VA_ARGS__); \
+} while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+#define TYPE_MPC_I2C "mpc-i2c"
+#define MPC_I2C(obj) \
+OBJECT_CHECK(MPCI2CState, (obj), TYPE_MPC_I2C)
+
+#define MPC_I2C_ADR   0x00
+#define MPC_I2C_FDR   0x04
+#define MPC_I2C_CR0x08
+#define MPC_I2C_SR0x0c
+#define MPC_I2C_DR0x10
+#define MPC_I2C_DFSRR 0x14
+
+#define CCR_MEN  (1 << 7)
+#define CCR_MIEN (1 << 6)
+#define CCR_MSTA (1 << 5)
+#define CCR_MTX  (1 << 4)
+#define CCR_TXAK (1 << 3)
+#define CCR_RSTA (1 << 2)
+#define CCR_BCST (1 << 0)
+
+#define CSR_MCF  (1 << 7)
+#define CSR_MAAS (1 << 6)
+#define CSR_MBB  (1 << 5)
+#define CSR_MAL  (1 << 4)
+#define CSR_SRW  (1 << 2)
+#define CSR_MIF  (1 << 1)
+#define CSR_RXAK (1 << 0)
+
+#define CADR_MASK 0xFE
+#define CFDR_MASK 0x3F
+#define CCR_MASK  0xFC
+#define CSR_MASK  0xED
+#define CDR_MASK  0xFF
+
+#define CYCLE_RESET 0xFF
+
+typedef struct MPCI2CState {
+SysBusDevice parent_obj;
+
+I2CBus *bus;
+qemu_irq irq;
+MemoryRegion iomem;
+
+uint8_t address;
+uint8_t adr;
+uint8_t fdr;
+uint8_t cr;
+uint8_t sr;
+uint8_t dr;
+uint8_t dfssr;
+} MPCI2CState;
+
+static bool mpc_i2c_is_enabled(MPCI2CState *s)
+{
+return s->cr & CCR_MEN;
+}
+
+static bool mpc_i2c_is_master(MPCI2CState *s)
+{
+return s->cr & CCR_MSTA;
+}
+
+static bool mpc_i2c_direction_is_tx(MPCI2CState *s)
+{
+return s->cr & CCR_MTX;
+}
+
+static bool mpc_i2c_irq_pending(MPCI2CState *s)
+{
+return s->sr & CSR_MIF;
+}
+
+static bool mpc_i2c_irq_is_enabled(MPCI2CState *s)
+{
+return s->cr & CCR_MIEN;
+}
+
+static void mpc_i2c_reset(DeviceState *dev)
+{
+MPCI2CState *i2c = MPC_I2C(dev);
+
+i2c->address = 0xFF;
+i2c->adr = 0x00;
+i2c->fdr = 0x00;
+i2c->cr =  0x00;
+i2c->sr =  0x81;
+i2c->dr =  0x00;
+}
+
+static void mpc_i2c_irq(MPCI2CState *s)
+{
+bool irq_active = false;
+
+if (mpc_i2c_is_enabled(s) && mpc_i2c_irq_is_enabled(s)
+  && mpc_i2c_irq_pending(s)) {
+irq_active = true;
+}
+
+if (irq

[Qemu-devel] Forward-porting RTC device for eppc500 ?

[Andrew Randrianasulu]

Hello, all!

I stumbled upon this email from 2015 (trying to understand why my emulated 
ppce500 machine failed to set clock correctly:

https://lists.gnu.org/archive/html/qemu-devel/2015-01/msg02642.html

Now, after some quite blind trial-and-error I applied ('forward-ported') this 
patch to qemu git commit 0f6a6d5db853c0cbe438c1831c70710bfb6530ee without 
actually porting it to new qemu device abstraction model.

It seems to work!

But because I copy-pasted patch from web archive of list - some strings 
become "address@hidden", I hope I corrected them right?

---
diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index 52acb7cf39..a560971f0c 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -8,6 +8,8 @@ include usb.mak
 CONFIG_PPC4XX=y
 CONFIG_M48T59=y
 CONFIG_SERIAL=y
+CONFIG_MPC_I2C=y
+CONFIG_DS1338=y
 CONFIG_I8257=y
 CONFIG_OPENPIC=y
 CONFIG_PPCE500_PCI=y
diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
index cecee486f7..55473fc6b2 100644
--- a/hw/i2c/Makefile.objs
+++ b/hw/i2c/Makefile.objs
@@ -9,5 +9,6 @@ common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
 common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
 common-obj-$(CONFIG_ASPEED_SOC) += aspeed_i2c.o
 common-obj-$(CONFIG_NRF51_SOC) += microbit_i2c.o
+common-obj-$(CONFIG_MPC_I2C) += mpc_i2c.o
 obj-$(CONFIG_OMAP) += omap_i2c.o
 obj-$(CONFIG_PPC4XX) += ppc4xx_i2c.o
diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
new file mode 100644
index 00..54d7a9aabd
--- /dev/null
+++ b/hw/i2c/mpc_i2c.c
@@ -0,0 +1,360 @@
+/*
+ * Copyright (C) 2014 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Amit Tomar, 
+ *
+ * Description:
+ * This file is derived from IMX I2C controller,
+ * by Jean-Christophe DUBOIS .
+ *
+ * Thanks to Scott Wood and Alexander Graf for their kind help on this.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2 or later,
+ * as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+*/
+
+#include "qemu/osdep.h"
+// #include "hw/i2c/imx_i2c.h"
+#include "hw/i2c/i2c.h"
+#include "qemu/log.h"
+#include "hw/sysbus.h"
+
+/* #define DEBUG_I2C */
+
+#ifdef DEBUG_I2C
+#define DPRINTF(fmt, ...)  \
+do { fprintf(stderr, "mpc_i2c[%s]: " fmt, __func__, ## __VA_ARGS__); \
+} while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+#define TYPE_MPC_I2C "mpc-i2c"
+#define MPC_I2C(obj) \
+OBJECT_CHECK(MPCI2CState, (obj), TYPE_MPC_I2C)
+
+#define MPC_I2C_ADR   0x00
+#define MPC_I2C_FDR   0x04
+#define MPC_I2C_CR0x08
+#define MPC_I2C_SR0x0c
+#define MPC_I2C_DR0x10
+#define MPC_I2C_DFSRR 0x14
+
+#define CCR_MEN  (1<<7)
+#define CCR_MIEN (1<<6)
+#define CCR_MSTA (1<<5)
+#define CCR_MTX  (1<<4)
+#define CCR_TXAK (1<<3)
+#define CCR_RSTA (1<<2)
+#define CCR_BCST (1<<0)
+
+#define CSR_MCF  (1<<7)
+#define CSR_MAAS (1<<6)
+#define CSR_MBB  (1<<5)
+#define CSR_MAL  (1<<4)
+#define CSR_SRW  (1<<2)
+#define CSR_MIF  (1<<1)
+#define CSR_RXAK (1<<0)
+
+#define CADR_MASK 0xFE
+#define CFDR_MASK 0x3F
+#define CCR_MASK  0xFC
+#define CSR_MASK  0xED
+#define CDR_MASK  0xFF
+
+#define CYCLE_RESET 0xFF
+
+typedef struct MPCI2CState {
+SysBusDevice parent_obj;
+
+I2CBus *bus;
+qemu_irq irq;
+MemoryRegion iomem;
+
+uint8_t address;
+uint8_t adr;
+uint8_t fdr;
+uint8_t cr;
+uint8_t sr;
+uint8_t dr;
+uint8_t dfssr;
+} MPCI2CState;
+
+static bool mpc_i2c_is_enabled(MPCI2CState *s)
+{
+return s->cr & CCR_MEN;
+}
+
+static bool mpc_i2c_is_master(MPCI2CState *s)
+{
+return s->cr & CCR_MSTA;
+}
+
+static bool mpc_i2c_direction_is_tx(MPCI2CState *s)
+{
+return s->cr & CCR_MTX;
+}
+
+static bool mpc_i2c_irq_pending(MPCI2CState *s)
+{
+return s->sr & CSR_MIF;
+}
+
+static bool mpc_i2c_irq_is_enabled(MPCI2CState *s)
+{
+return s->cr & CCR_MIEN;
+}
+
+static void mpc_i2c_reset(DeviceState *dev)
+{
+MPCI2CState *i2c = MPC_I2C(dev);
+
+i2c->address = 0xFF;
+i2c->adr = 0x00;
+i2c->fdr = 0x00;
+i2c->cr =  0x00;
+i2c->sr =  0x81;
+i2c->dr =  0x00;
+}
+
+static void mpc_i2c_irq(MPCI2CState *s)
+{
+bool irq_active = false;
+
+if (mpc_i2c_is_enabled(s) && mpc_i2c_irq_is_enabled(s)
+  && mpc_i2c_irq_pending(s)) {
+irq_active = true;
+}
+
+if (irq_active) {
+qemu_irq_raise(s->irq);
+} else {
+qemu_irq_lower(s->irq);
+}
+}
+
+static void mpc_i2c_soft_reset(MPCI2CState *s)
+{
+/* This is a soft reset. ADR is preserved during soft resets */
+uint8_t adr = s->adr;
+mpc_i2c_reset(DEVICE(s));
+s->adr = adr;
+}
+
+static void  mpc_i2c_address_send(MPCI2CState *s)
+{
+/* if returns non zero slave address is not right */
+if 

Re: [Qemu-devel] regression: target/ppc: convert VSX logical operations to vector operations broke X for ppc64le guest

[Andrew Randrianasulu]

В сообщении от Thursday 28 February 2019 08:06:45 Mark Cave-Ayland написал(а):
> On 26/02/2019 22:25, Andrew Randrianasulu wrote:
>
> (adding qemu-ppc, Richard and David - please make sure you add the relevant
> maintainer on bug reports, as otherwise due to the high volume of mails to
> the list it's very easy to miss things)

ok


>
> > Hello.
> >
> > I bisected this problem with fonts (and multicolored vertical stripes) in
> > qemu git (ppc64-softmmu)
> >
> > guest@slax:/dev/shm/qemu$ git bisect good
> > 7b8fe477e12b164dda97f79e27b55b805d90384f is the first bad commit
> > commit 7b8fe477e12b164dda97f79e27b55b805d90384f
> > Author: Richard Henderson 
> > Date:   Fri Feb 15 10:00:46 2019 +
> >
> > target/ppc: convert VSX logical operations to vector operations
> >
> > Signed-off-by: Richard Henderson 
> > Acked-by: David Gibson 
> > Message-Id: <20190215100058.20015-6-mark.cave-ayl...@ilande.co.uk>
> > Signed-off-by: David Gibson 
> >
> > :04 04 da3024ad2c9dfc3b7170516a8b321ef8c5d5bdf8
> >
> > a0257b9f5880ecc8e7001a59ccaa10407084623f M  target
> >
> >
> > guest@slax:/dev/shm/qemu$ git bisect log
> > git bisect start
> > # good: [32a1a94dd324d33578dca1dc96d7896a0244d768] Update version for
> > v3.1.0 release
> > git bisect good 32a1a94dd324d33578dca1dc96d7896a0244d768
> > # bad: [86c7e2f4a93322a76afea5ee6806a83420d1dfea] Merge remote-tracking
> > branch 'remotes/berrange/tags/authz-core-pull-request' into staging
> > git bisect bad 86c7e2f4a93322a76afea5ee6806a83420d1dfea
> > # good: [95ebd99dcd37b8574426c876502bfcc7c299584b] target/arm: Decode
> > PAuth within disas_data_proc_1src
> > git bisect good 95ebd99dcd37b8574426c876502bfcc7c299584b
> > # good: [268dfefa690b2bdee1f8c5090d2343871cf3467c]
> > hw/microblaze/Makefile.objs: Create configs for petalogix and xilinx
> > boards
> > git bisect good 268dfefa690b2bdee1f8c5090d2343871cf3467c
> > # good: [f5117fd28552fe3fe32ef0495582b1caaef7a28d] hw/mips_cpc: kick a VP
> > when putting it into Run statewq
> > git bisect good f5117fd28552fe3fe32ef0495582b1caaef7a28d
> > # bad: [2e68b8620637a4ee8c79b5724144b726af1e261b] Merge remote-tracking
> > branch 'remotes/dgibson/tags/ppc-for-4.0-20190219' into staging
> > git bisect bad 2e68b8620637a4ee8c79b5724144b726af1e261b
> > # good: [4c668f4a3d684ec133a52d936314379f6edd672e] target/ppc: Remove
> > some #if 0'ed code
> > git bisect good 4c668f4a3d684ec133a52d936314379f6edd672e
> > # bad: [9b5b74da0a07a89ef71c7f7da0b36560a3bac521] target/ppc: Split out
> > VSCR_SAT to a vector field
> > git bisect bad 9b5b74da0a07a89ef71c7f7da0b36560a3bac521
> > # good: [444d6ca301d97de141a502851940943b09a9ebee] spapr/irq: Use the
> > "simple" ICS class for KVM
> > git bisect good 444d6ca301d97de141a502851940943b09a9ebee
> > # bad: [9bb0048ec6f8f3bcc144b2c5769d9301e824f946] target/ppc: convert
> > xxspltw to vector operations
> > git bisect bad 9bb0048ec6f8f3bcc144b2c5769d9301e824f946
> > # good: [471ff3d0257135b938d0a5f2181f22cd753d50de] target/ppc: convert
> > vspltis[bhw] to use vector operations
> > git bisect good 471ff3d0257135b938d0a5f2181f22cd753d50de
> > # bad: [7b8fe477e12b164dda97f79e27b55b805d90384f] target/ppc: convert VSX
> > logical operations to vector operations
> > git bisect bad 7b8fe477e12b164dda97f79e27b55b805d90384f
> > # good: [0f6a6d5db853c0cbe438c1831c70710bfb6530ee] target/ppc: convert
> > vsplt[bhw] to use vector operations
> > git bisect good 0f6a6d5db853c0cbe438c1831c70710bfb6530ee
> > # first bad commit: [7b8fe477e12b164dda97f79e27b55b805d90384f]
> > target/ppc: convert VSX logical operations to vector operations
> > guest@slax:/dev/shm/qemu$
> >
> > configure line:
> > setarch i686 ./configure --target-list=ppc64-softmmu
> >
> > launch line:
> > ppc64-softmmu/qemu-system-ppc64 -display
> > sdl,gl=on -hda /mnt/sdb1/PPC-img/alpine_disk.img
> >
> > where alpine_disk.img is HDD installed Alpine 3.7 for ppc64le with xfce4
> > desktop.
>
> AFAICT the vector instructions converted here are independent of endian, so
> I can't see why this patch on its own would have any effect.
>
> Maybe it could be because the "setarch i686" part forces use of some
> lesser-used 32-bit paths in the vector code - is this required? And do you
> see the same issue on a x86_64 build?

I use 32-bit Slackware userland with x86_64 kerenl - so setarch prevent most of 
configures from detecting my arch wrongly.

Yes, bug was and is present with qemu compiled for x86_64 (inside chroot).
I initially discovered it there, and after dropping -O3 and even march=native, 
and even disabling avx2 via configure switch - moved to bisect.

https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg06414.html

>
>
> ATB,
>
> Mark.

[Qemu-devel] regression: target/ppc: convert VSX logical operations to vector operations broke X for ppc64le guest

[Andrew Randrianasulu]

Hello.

I bisected this problem with fonts (and multicolored vertical stripes) in qemu 
git (ppc64-softmmu)

guest@slax:/dev/shm/qemu$ git bisect good
7b8fe477e12b164dda97f79e27b55b805d90384f is the first bad commit
commit 7b8fe477e12b164dda97f79e27b55b805d90384f
Author: Richard Henderson 
Date:   Fri Feb 15 10:00:46 2019 +

target/ppc: convert VSX logical operations to vector operations

Signed-off-by: Richard Henderson 
Acked-by: David Gibson 
Message-Id: <20190215100058.20015-6-mark.cave-ayl...@ilande.co.uk>
Signed-off-by: David Gibson 

:04 04 da3024ad2c9dfc3b7170516a8b321ef8c5d5bdf8 
a0257b9f5880ecc8e7001a59ccaa10407084623f M  target


guest@slax:/dev/shm/qemu$ git bisect log
git bisect start
# good: [32a1a94dd324d33578dca1dc96d7896a0244d768] Update version for v3.1.0 
release
git bisect good 32a1a94dd324d33578dca1dc96d7896a0244d768
# bad: [86c7e2f4a93322a76afea5ee6806a83420d1dfea] Merge remote-tracking 
branch 'remotes/berrange/tags/authz-core-pull-request' into staging
git bisect bad 86c7e2f4a93322a76afea5ee6806a83420d1dfea
# good: [95ebd99dcd37b8574426c876502bfcc7c299584b] target/arm: Decode PAuth 
within disas_data_proc_1src
git bisect good 95ebd99dcd37b8574426c876502bfcc7c299584b
# good: [268dfefa690b2bdee1f8c5090d2343871cf3467c] hw/microblaze/Makefile.objs: 
Create configs for petalogix and xilinx boards
git bisect good 268dfefa690b2bdee1f8c5090d2343871cf3467c
# good: [f5117fd28552fe3fe32ef0495582b1caaef7a28d] hw/mips_cpc: kick a VP when 
putting it into Run statewq
git bisect good f5117fd28552fe3fe32ef0495582b1caaef7a28d
# bad: [2e68b8620637a4ee8c79b5724144b726af1e261b] Merge remote-tracking 
branch 'remotes/dgibson/tags/ppc-for-4.0-20190219' into staging
git bisect bad 2e68b8620637a4ee8c79b5724144b726af1e261b
# good: [4c668f4a3d684ec133a52d936314379f6edd672e] target/ppc: Remove some #if 
0'ed code
git bisect good 4c668f4a3d684ec133a52d936314379f6edd672e
# bad: [9b5b74da0a07a89ef71c7f7da0b36560a3bac521] target/ppc: Split out 
VSCR_SAT 
to a vector field
git bisect bad 9b5b74da0a07a89ef71c7f7da0b36560a3bac521
# good: [444d6ca301d97de141a502851940943b09a9ebee] spapr/irq: Use the "simple" 
ICS class for KVM
git bisect good 444d6ca301d97de141a502851940943b09a9ebee
# bad: [9bb0048ec6f8f3bcc144b2c5769d9301e824f946] target/ppc: convert xxspltw 
to 
vector operations
git bisect bad 9bb0048ec6f8f3bcc144b2c5769d9301e824f946
# good: [471ff3d0257135b938d0a5f2181f22cd753d50de] target/ppc: convert 
vspltis[bhw] to use vector operations
git bisect good 471ff3d0257135b938d0a5f2181f22cd753d50de
# bad: [7b8fe477e12b164dda97f79e27b55b805d90384f] target/ppc: convert VSX 
logical operations to vector operations
git bisect bad 7b8fe477e12b164dda97f79e27b55b805d90384f
# good: [0f6a6d5db853c0cbe438c1831c70710bfb6530ee] target/ppc: convert 
vsplt[bhw] to use vector operations
git bisect good 0f6a6d5db853c0cbe438c1831c70710bfb6530ee
# first bad commit: [7b8fe477e12b164dda97f79e27b55b805d90384f] target/ppc: 
convert VSX logical operations to vector operations
guest@slax:/dev/shm/qemu$

configure line:
setarch i686 ./configure --target-list=ppc64-softmmu 

launch line:
ppc64-softmmu/qemu-system-ppc64 -display 
sdl,gl=on -hda /mnt/sdb1/PPC-img/alpine_disk.img

where alpine_disk.img is HDD installed Alpine 3.7 for ppc64le with xfce4 
desktop.

   

Re: [Qemu-devel] Build error with git commit 8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116 on x86_64

[Andrew Randrianasulu]

В сообщении от Tuesday 26 February 2019 12:58:11 вы написали:
> On 26/02/2019 10.46, Andrew Randrianasulu wrote:
> [...]
>
> > also, -g 1186x864x32 resulted in funnuy diagonal corruption even at
> > firmware screen level, and probably same happening with x86-64/kvm guest
> > if I select some less comon, but exposed via xrandr mode. (this bit for
> > -vga std, default)
>
> 1186 is not dividable by 16 ... you likely meant 1184 instead?
>
>  Thomas

yeah, just forgot exact number ..
not sure if it really bug or feature. Should qemu check (and enforce? or just 
warn about?) those parameters, if specific video driver can't cope with 
specific resolutions? 

I also looked at offb sources:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev/offb.c?h=v5.0-rc8

hm, because by default stdvga initialized by openfrmware to truecolor mode (32 
bpp), then I assume cmap hacks not really applicable in this case? I'll try to 
play with switch at line 446 and specifically 'case 32' at line 480 ...

Re: [Qemu-devel] Build error with git commit 8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116 on x86_64

[Andrew Randrianasulu]

В сообщении от Tuesday 26 February 2019 12:05:02 Thomas Huth написал(а):
> On 26/02/2019 09.58, Andrew Randrianasulu wrote:
> > В сообщении от Tuesday 26 February 2019 11:54:12 вы написали:
> >> On 25/02/2019 18.29, Andrew Randrianasulu wrote:
> >>> В сообщении от Monday 25 February 2019 19:19:01 Philippe
> >>> Mathieu-Daudc3a9
> >>>
> >>> написал(а):
> >>>> Hi Andrew,
> >>>>
> >>>> On 2/23/19 1:35 AM, Andrew Randrianasulu wrote:
> >>>>> Hello!
> >>>>>
> >>>>> I just pulled latest git
> >>>>
> >>>> [...]
> >>>>
> >>>>> and default build with simple ./configure on slackware 14.2 x86-64
> >>>>> box failed like this:
> >>>>>
> >>>>> root@slax:~/src/qemu# LANG=C make -j 5
> >>>>> CHK version_gen.h
> >>>>>   CC  qobject/block-qdict.o
> >>>>>   CC  util/thread-pool.o
> >>>>>   CC  util/main-loop.o
> >>>>>   CC  util/qemu-timer.o
> >>>>>   CC  util/iohandler.o
> >>>>>   CC  util/aio-posix.o
> >>>>> qobject/block-qdict.c: In function 'qdict_array_split':
> >>>>> qobject/block-qdict.c:259:9: error: 'subqdict' may be used
> >>>>> uninitialized in this function [-Werror=maybe-uninitialized]
> >>>>>  qlist_append_obj(*dst, subqobj ?: QOBJECT(subqdict));
> >>>>>  ^
> >>>>
> >>>> That's odd, I can not reproduce with a simple ./configure:
> >>>>
> >>>> $ cat /etc/slackware-version
> >>>> Slackware 14.2
> >>>>
> >>>> $ gcc --version
> >>>> gcc (GCC) 5.5.0
> >>>
> >>> Well, then may be this is false positive, right now another qemu
> >>> instance is busy inside same chroot, will try patch posted in earlier
> >>> mail (after removing CFLAG I added for compiling qemu at all after this
> >>> error).
> >>>
> >>> Thanks for trying to reproduce.
> >>
> >> Just to be sure: You don't compile with -O3 or -O1 or -O0 in the CFLAGS
> >> here, do you?
> >
> > This time  it was -O3, but I got some corruption in ppc64le guest's X, so
> > I plan to revert this -O3 back to default 
>
> Ok, then that's the problem here: GCC often produces some additional
> "may be unused" warnings with -O3, and we normally only guarantee that
> QEMU compiles without warnings when using the standard -O2 optimization
> level.
> So if you want to compile with -O3, you also have to specify
> --disable-werror (or add -Wno-error=maybe-unitialized to the CFLAGS).
> But unless you have really an urgent need for O3, I'd rather recommend
> to compile with the well-tested O2 optimization level instead.

Ok, will do 

I was hoping for some speed-up in (mt)tcg based machines, because compiling big 
programs inside qemu obviously not ultrafast.

3916 root  20   0 5442m 2.8g 3396 R  213 24.0   2758:40 qemu-system-ppc

from 'top' on host.

But then, soon-to-be 4.0 qemu should be faster in general due to all those tcg 
optimizations, so -O3 really will be dropped on my side.

Still, I have more funny observations, like this blue screen with qemu's -vga 
virtio/cirrus was present even on 2.12+, but this probably offb bug (assumes BE 
when compiled for power?) .

And 
root@slax:~/src/qemu# qemu-system-ppc64 -m 2G -display sdl,gl=on -smp 
3  -hda /mnt/alpine_disk.img -g 1120x832x24

somewhat resulted in 8-bit X display (xf86-video-fbdev over offb, i think. due 
to 'nomodeset' default in alpine kernel - another reason to recompile {first 
reason was es1370 audio device support} and alter some parameters..) 

:)

In some sense this is cool, because I can see same problem with not loading png 
images into Cinelerra-GG itself, even on 8-bit display (without GLX and 
composite), but may be it was not intended.

will look into offb's sources ...

also, -g 1186x864x32 resulted in funnuy diagonal corruption even at firmware 
screen level, and probably same happening with x86-64/kvm guest if I select 
some less comon, but exposed via xrandr mode. (this bit for -vga std, default)

>
>  Thomas

Re: [Qemu-devel] Build error with git commit 8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116 on x86_64

[Andrew Randrianasulu]

В сообщении от Tuesday 26 February 2019 11:54:12 вы написали:
> On 25/02/2019 18.29, Andrew Randrianasulu wrote:
> > В сообщении от Monday 25 February 2019 19:19:01 Philippe Mathieu-Daudc3a9
> >
> > написал(а):
> >> Hi Andrew,
> >>
> >> On 2/23/19 1:35 AM, Andrew Randrianasulu wrote:
> >>> Hello!
> >>>
> >>> I just pulled latest git
> >>
> >> [...]
> >>
> >>> and default build with simple ./configure on slackware 14.2 x86-64 box
> >>> failed like this:
> >>>
> >>> root@slax:~/src/qemu# LANG=C make -j 5
> >>> CHK version_gen.h
> >>>   CC  qobject/block-qdict.o
> >>>   CC  util/thread-pool.o
> >>>   CC  util/main-loop.o
> >>>   CC  util/qemu-timer.o
> >>>   CC  util/iohandler.o
> >>>   CC  util/aio-posix.o
> >>> qobject/block-qdict.c: In function 'qdict_array_split':
> >>> qobject/block-qdict.c:259:9: error: 'subqdict' may be used
> >>> uninitialized in this function [-Werror=maybe-uninitialized]
> >>>  qlist_append_obj(*dst, subqobj ?: QOBJECT(subqdict));
> >>>  ^
> >>
> >> That's odd, I can not reproduce with a simple ./configure:
> >>
> >> $ cat /etc/slackware-version
> >> Slackware 14.2
> >>
> >> $ gcc --version
> >> gcc (GCC) 5.5.0
> >
> > Well, then may be this is false positive, right now another qemu instance
> > is busy inside same chroot, will try patch posted in earlier mail (after
> > removing CFLAG I added for compiling qemu at all after this error).
> >
> > Thanks for trying to reproduce.
>
> Just to be sure: You don't compile with -O3 or -O1 or -O0 in the CFLAGS
> here, do you?

This time  it was -O3, but I got some corruption in ppc64le guest's X, so I 
plan 
to revert this -O3 back to default 

another qemu still busy compiling kernel (modified Alpine linux ppc64le 
config), 
and also Cinelerra-GG (video editor I'm hacking on), so I hope whole thing will 
be finished ..in day or so.

>
>  Thomas

Re: [Qemu-devel] Build error with git commit 8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116 on x86_64

[Andrew Randrianasulu]

В сообщении от Monday 25 February 2019 19:19:01 Philippe Mathieu-Daudc3a9 
написал(а):
> Hi Andrew,
>
> On 2/23/19 1:35 AM, Andrew Randrianasulu wrote:
> > Hello!
> >
> > I just pulled latest git
>
> [...]
>
> > and default build with simple ./configure on slackware 14.2 x86-64 box
> > failed like this:
> >
> > root@slax:~/src/qemu# LANG=C make -j 5
> > CHK version_gen.h
> >   CC  qobject/block-qdict.o
> >   CC  util/thread-pool.o
> >   CC  util/main-loop.o
> >   CC  util/qemu-timer.o
> >   CC  util/iohandler.o
> >   CC  util/aio-posix.o
> > qobject/block-qdict.c: In function 'qdict_array_split':
> > qobject/block-qdict.c:259:9: error: 'subqdict' may be used uninitialized
> > in this function [-Werror=maybe-uninitialized]
> >  qlist_append_obj(*dst, subqobj ?: QOBJECT(subqdict));
> >  ^
>
> That's odd, I can not reproduce with a simple ./configure:
>
> $ cat /etc/slackware-version
> Slackware 14.2
>
> $ gcc --version
> gcc (GCC) 5.5.0
>

Well, then may be this is false positive, right now another qemu instance is 
busy inside same chroot, will try patch posted in earlier mail (after removing 
CFLAG I added for compiling qemu at all after this error).

Thanks for trying to reproduce.

> >  LANG=C gcc --version
> > gcc (GCC) 5.5.0
> > Copyright (C) 2015 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is
> > NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.

[Qemu-devel] Possible ppc64le regression in master?

[Andrew Randrianasulu]

Hello again.

I was trying to set up virtual ppc64le machine with some linux inside. First 
tried with qemu-3.1 on 32-bit host. It worked, but was slow-ish.

next I tred to compile latest qemu git (up to commit 
8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116) on 64-bit Slackware, to get MTTCG 
acceleration.

qemu was successfully compiled with those CFLAGS:


CFLAGS=-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -O3 -march=native 
-mtune=native -Wno-maybe-uninitialized

but then when I tried to run it - console was fine, but X inside Alpine Linux 
was all striped!

Going back to 2.12+ compiled last year fixed this issue to me, X is back to 
normal.

I was using this guide:
https://buggy.link/2018/01/31/ppc64le-on-x86_64-qemu-full-system-emulation.html

Command lines tried:

root@slax:~/src/qemu# ppc64-softmmu/qemu-system-ppc64 -m 1024 -display 
sdl,gl=on -smp 3 -hda /mnt/alpine_disk.img -> corruption in X, console ok.

ppc64-softmmu/qemu-system-ppc64 -m 1024 -display sdl,gl=on -vga virtio -smp 3 
-M 
pseries-3.1 -hda /mnt/alpine_disk.img -> even console is blue!

root@slax:~/src/qemu# ppc64-softmmu/qemu-system-ppc64 -m 1024 -display 
sdl,gl=on -vga cirrus -smp 1 -M pseries-3.1 -hda /mnt/alpine_disk.img -> same 
blue screen even on console

root@slax:~/src/qemu# ppc64-softmmu/qemu-system-ppc64 -m 1024 -smp 4 -M 
pseries-3.1 -hda /mnt/alpine_disk.img - this defaulted to gtk UI, and  X was 
corrupted anyway :/

root@slax:~/src/qemu# ppc64-softmmu/qemu-system-ppc64 -m 1024 -display 
sdl,gl=on -smp 1 -M pseries-3.1 -hda /mnt/alpine_disk.img -g 1024x768x32 - nice 
big console with correct colors, but X still corrupt!

root@slax:~/src/qemu# qemu-system-ppc64 -m 1024 -display sdl,gl=on -smp 
3  -hda /mnt/alpine_disk.img -g 1024x768x32 -> old qemu still works OK, booted 
right now and compiling stuff.

Attached are files I modified on Alpine install - custom xorg.conf, .xinitrc 
and 
ash_history (so you can install same set of packages as I)

My host CPU is:
cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 21
model   : 2
model name  : AMD FX(tm)-4300 Quad-Core Processor
stepping: 0
microcode   : 0x6000852
cpu MHz : 3222.725
cache size  : 2048 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 16
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf 
pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c 
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch 
osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core 
perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save 
tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bugs: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 
spec_store_bypass
bogomips: 7599.87
TLB size: 1536 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

so, with avx.

I'll try to recompile with less agressive optimizations, and if this will not 
help - bisect .

Thanks for attention.
apk update
apk upgrade
mc
apk ?
apk --help
apk lsit mc
apk list mc
apk add mc
apk list xorg
apk list xserver
apk list 
apk list perl
apk add perl pythong gcc git svn 
apk add perl python gcc git svn 
apk add perl python gcc git 
top
setup-xorg=base
setup-xorg-base
setup-udev
ps axv
killall -9 apk
apk lsit subversion
apk list subversion
apk add subversion
setup-xorg-base
apk list xfce
apk list fluxbox
apk app fluxbox
apk add fluxbox
apk list xterm
apk list term
apk list *term
apk list | grep term
apk add lxterminal
apk list | grep ffmpeg
apk add ffmpeg
startx
mcedit /etc/X11/xorg.conf
startx
mcedit /etc/X11/xorg.conf
startx
startx -depth 8
lspci
dmesg 
dmesg | grep drm
dmesg | grep boch
dmesg | grep bonch
dmesg | grep fb
apk add mplayer
apk add mpg123
apk add ogg123
apk add ogg321
apk add vorbis-tools
apk add vorbis
apk list | grep vorbis
apk add libvorbis-dev
apk list | grep fbset
apk add fbset
mcedit /etc/X11/xorg.conf
startx
X -configure
apk list | grep fbdev
apk add xf86-video-fbdev
X -configure
startx
apk list | grep xinit
mcedit .xinitrc
startx
apk list | grep xterm
apk list | grep menu
apk add dmenu
apk list | grep xfce
apk add xfce4
startx
mcedit .xinitrc 
startx
uptime
apk add xrandr
xrandr 
xdpyinfo
apk add xdpyinfo
apk list *-dev
apk add *-dev
apk --help
apk add libx11-dev-1.6.6-r0
apk add libx11-dev
apk add ffmpeg-dev
apk list firefox
apk list links
apk add links
apk add imlib2-dev
apk add libxml2-dev
mkdir src
apk add a52dec-dev
ls
cd src
links cinelerr

[Qemu-devel] Build error with git commit 8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116 on x86_64

[Andrew Randrianasulu]

Hello!

I just pulled latest git

up to 
commit 8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116 (HEAD -> master, origin/master, 
origin/HEAD)
Merge: a05838cb2a 2b6326c0bf
Author: Peter Maydell 
Date:   Fri Feb 22 15:48:04 2019 +

Merge remote-tracking branch 
'remotes/awilliam/tags/vfio-updates-20190221.0' 
into staging

VFIO updates 2019-02-21

 - Workaround kernel overflow bug in vfio type1 DMA unmap
   (Alex Williamson)

 - Refactor vfio container initialization (Eric Auger)

# gpg: Signature made Fri 22 Feb 2019 05:21:07 GMT
# gpg:using RSA key 239B9B6E3BB08B22
# gpg: Good signature from "Alex Williamson " 
[full]
# gpg: aka "Alex Williamson " [full]
# gpg: aka "Alex Williamson " [full]
# gpg: aka "Alex Williamson " 
[full]
# Primary key fingerprint: 42F6 C04E 540B D1A9 9E7B  8A90 239B 9B6E 3BB0 
8B22

* remotes/awilliam/tags/vfio-updates-20190221.0:
  hw/vfio/common: Refactor container initialization
  vfio/common: Work around kernel overflow bug in DMA unmap

Signed-off-by: Peter Maydell 
-

and default build with simple ./configure on slackware 14.2 x86-64 box failed 
like this:

root@slax:~/src/qemu# LANG=C make -j 5
CHK version_gen.h
  CC  qobject/block-qdict.o
  CC  util/thread-pool.o
  CC  util/main-loop.o
  CC  util/qemu-timer.o
  CC  util/iohandler.o
  CC  util/aio-posix.o
qobject/block-qdict.c: In function 'qdict_array_split':
qobject/block-qdict.c:259:9: error: 'subqdict' may be used uninitialized in 
this 
function [-Werror=maybe-uninitialized]
 qlist_append_obj(*dst, subqobj ?: QOBJECT(subqdict));
 ^
  CC  util/compatfd.o
  CC  util/event_notifier-posix.o
cc1: all warnings being treated as errors
/root/src/qemu/rules.mak:69: recipe for target 'qobject/block-qdict.o' failed
make: *** [qobject/block-qdict.o] Error 1
make: *** Waiting for unfinished jobs


 LANG=C gcc --version
gcc (GCC) 5.5.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

---

Re: [Qemu-devel] Qemu the right way -[Subthread Cores]

[Andrew Randrianasulu]

> Since I do not have networking sorted out yet I cannot update win7 pro, and 
> it 
might be the updates which are needed for allowing more than two cpus.

hm, brief search on my side resulted in this tip:

https://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/windows-7-professional-x64-only-showing-2-of-8/0155f525-df73-4642-a828-21b80d1564b0

--
Some recommendations (in Windows, make sure you are running as Administrator):
 
- Run MSConfig -> Change to Boot tab -> Advanced Options -> "Number of 
Processors", make sure there is no check mark.
- Delete processor entries listed in Device Manager, then reboot.

-

(I don't think BIOS options from this answer really apply directly to qemu case)

also, if win (or some applications inside it) keep crashing with -cpu host, you 
can try to reload host (Linux) kvm module with additional option:

"options kvm ignore_msrs=1" line (without quotes) should be added to
 /etc/modprobe.d/kvm.conf

from 
https://www.passmark.com/forum/performancetest/4748-startup-error-number-4-on-qemu-bsod

[Qemu-devel] qemu-system_x86-64 (32-bit binary) -M q35 can be crashed on viewing youtube.

[Andrew Randrianasulu]

It was crashing and crashing, so I tried to debug it a bit ... 


valgrind --leak-check=yes /dev/shm/qemu/x86_64-softmmu/qemu-system-x86_64  
-display 
sdl,gl=on  -M q35 -soundhw 
hda -cdrom /home/guest/Downloads/ISO/slax-English-US-7.0.8-x86_64.iso -m 
1G -enable-kvm -d trace:e1000e*   shows some errors at very end, see attached 
file.

For reproduction, wait for liveCD to finish loading, start firefox, go to 
youtube.com, it will warn you about outdated browser but continue anyway, try 
to click on any video 

It seems even modern KDE Neon distribution affected by same bug :/
--quote-

29362@1532305439.464672:e1000e_core_write Write to register 0xd0, 4 byte(s), 
value: 0x10
29362@1532305439.464735:e1000e_irq_set_ims Setting IMS bits 0x10: 
0x154 --> 0x154
29362@1532305439.464791:e1000e_irq_msix_pending_clearing Clearing MSI-X pending 
bit for cause 0x10, IVAR config 0x800a0908, vector 0
29362@1532305439.464867:e1000e_irq_fix_icr_asserted ICR_ASSERTED bit fixed: 
0x8002
29362@1532305439.464916:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 
0x8002, IMS: 0x154)
29362@1532305439.524010:e1000e_core_write Write to register 0x3818, 4 byte(s), 
value: 0x97
29362@1532305439.524097:e1000e_tx_descr 0x21180e : 27000b68 5b43600
29362@1532305439.524169:e1000e_tx_descr 0x3bf970fa : 261005c6 300
29362@1532305439.524248:e1000e_tx_descr 0x1c1c8000 : af1005d8 300
==29362== Invalid write of size 4
==29362==at 0x552E58: memcpy (string3.h:53)
==29362==by 0x552E58: m_cat (mbuf.c:143)
==29362==by 0x54FE1E: ip_reass (ip_input.c:341)
==29362==by 0x54FE1E: ip_input (ip_input.c:190)
==29362==by 0x552478: slirp_input (slirp.c:874)
==29362==by 0x53FBE7: net_slirp_receive (slirp.c:121)
==29362==by 0x537478: nc_sendv_compat (net.c:701)
==29362==by 0x537478: qemu_deliver_packet_iov (net.c:728)
==29362==by 0x53A649: qemu_net_queue_deliver_iov (queue.c:179)
==29362==by 0x53A649: qemu_net_queue_send_iov (queue.c:224)
==29362==by 0x538901: qemu_sendv_packet_async (net.c:764)
==29362==by 0x538925: qemu_sendv_packet (net.c:772)
==29362==by 0x53AB71: net_hub_receive_iov (hub.c:73)
==29362==by 0x53AB71: net_hub_port_receive_iov (hub.c:124)
==29362==by 0x53748D: qemu_deliver_packet_iov (net.c:726)
==29362==by 0x53A649: qemu_net_queue_deliver_iov (queue.c:179)
==29362==by 0x53A649: qemu_net_queue_send_iov (queue.c:224)
==29362==by 0x538901: qemu_sendv_packet_async (net.c:764)
==29362==  Address 0x114f9b60 is 0 bytes after a block of size 2,976 alloc'd
==29362==at 0x482B29C: malloc (vg_replace_malloc.c:299)
==29362==by 0x534D3E1: g_malloc (in /usr/lib/libglib-2.0.so.0.4600.2)
==29362==by 0x552B53: m_inc.part.1 (mbuf.c:166)
==29362==by 0x552EAE: m_inc (string3.h:53)
==29362==by 0x552EAE: m_cat (mbuf.c:141)
==29362==by 0x54FE1E: ip_reass (ip_input.c:341)
==29362==by 0x54FE1E: ip_input (ip_input.c:190)
==29362==by 0x552478: slirp_input (slirp.c:874)
==29362==by 0x53FBE7: net_slirp_receive (slirp.c:121)
==29362==by 0x537478: nc_sendv_compat (net.c:701)
==29362==by 0x537478: qemu_deliver_packet_iov (net.c:728)
==29362==by 0x53A649: qemu_net_queue_deliver_iov (queue.c:179)
==29362==by 0x53A649: qemu_net_queue_send_iov (queue.c:224)
==29362==by 0x538901: qemu_sendv_packet_async (net.c:764)
==29362==by 0x538925: qemu_sendv_packet (net.c:772)
==29362==by 0x53AB71: net_hub_receive_iov (hub.c:73)
==29362==by 0x53AB71: net_hub_port_receive_iov (hub.c:124)
==29362==
==29362== Invalid write of size 4
==29362==at 0x552E5E: memcpy (string3.h:53)
==29362==by 0x552E5E: m_cat (mbuf.c:143)
==29362==by 0x54FE1E: ip_reass (ip_input.c:341)
==29362==by 0x54FE1E: ip_input (ip_input.c:190)
==29362==by 0x552478: slirp_input (slirp.c:874)
==29362==by 0x53FBE7: net_slirp_receive (slirp.c:121)
==29362==by 0x537478: nc_sendv_compat (net.c:701)
==29362==by 0x537478: qemu_deliver_packet_iov (net.c:728)
==29362==by 0x53A649: qemu_net_queue_deliver_iov (queue.c:179)
==29362==by 0x53A649: qemu_net_queue_send_iov (queue.c:224)
==29362==by 0x538901: qemu_sendv_packet_async (net.c:764)
==29362==by 0x538925: qemu_sendv_packet (net.c:772)
==29362==by 0x53AB71: net_hub_receive_iov (hub.c:73)
==29362==by 0x53AB71: net_hub_port_receive_iov (hub.c:124)
==29362==by 0x53748D: qemu_deliver_packet_iov (net.c:726)
==29362==by 0x53A649: qemu_net_queue_deliver_iov (queue.c:179)
==29362==by 0x53A649: qemu_net_queue_send_iov (queue.c:224)
==29362==by 0x538901: qemu_sendv_packet_async (net.c:764)
==29362==  Address 0x114f9b78 is 24 bytes before an unallocated block of size 
156,632 in arena "client"
==29362==
==29362== Invalid write of size 4
==29362==at 0x552E6B: memcpy (string3.h:53)
==29362==by 0x552E6B: m_cat (mbuf.c:143)
==29362==by 0x54FE1E: ip_reass (ip_input.c:341)
==29362==by 0x54FE1E: ip_input (ip_input.c:190)

[Qemu-devel] qemu-system-ppc -M mac99 and -soundhw es1370 doesn't start

[Andrew Randrianasulu]

Hello!

Currently I'm trying pre-releases of qemu, for avoiding situation when release 
was too bugged (2.12, for my taste ..qemu-system-alpha was broken, 
qemu-system-x86_64 -M q35 was broken ..) 

using 
qemu-system-ppc --version
QEMU emulator version 2.12.91 (v3.0.0-rc1-17-g5b3ecd3d94-dirty)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

I can't start qemu-system-ppc with -M mac99 and -soundhw es1370:

qemu-system-ppc -monitor stdio -soundhw es1370 -vga std -M mac99
QEMU 2.12.91 monitor - type 'help' for more information
(qemu) qemu-system-ppc: PCI bus not available for es1370

qemu-system-ppc64 starts fine:
emu-system-ppc64 -monitor stdio -soundhw es1370 -vga std -M mac99
QEMU 2.12.91 monitor - type 'help' for more information
(qemu) info pci
  Bus  0, device  11, function 0:
Host bridge: PCI device 106b:004b
  id ""
  Bus  0, device  12, function 0:
Class 65280: PCI device 106b:0022
  BAR0: 32 bit memory at 0x8000 [0x8007].
  id ""
  Bus  0, device  13, function 0:
USB controller: PCI device 106b:003f
  IRQ 28.
  BAR0: 32 bit memory at 0x8008 [0x800800ff].
  id ""
  Bus  0, device  14, function 0:
VGA controller: PCI device 1234:
  BAR0: 32 bit prefetchable memory at 0x8100 [0x81ff].
  BAR2: 32 bit memory at 0x8200 [0x82000fff].
  BAR6: 32 bit memory at 0x8201 [0x8201].
  id ""
  Bus  0, device  15, function 0:
Ethernet controller: PCI device 10ec:8029
  IRQ 30.
  BAR0: I/O at 0x1000 [0x10ff].
  BAR6: 32 bit memory at 0x8204 [0x8207].
  id ""
  Bus  0, device  16, function 0:
Audio controller: PCI device 1274:5000
  IRQ 27.
  BAR0: I/O at 0x1100 [0x11ff].
  id ""
(qemu) 

Note, I'm using 32-bit qemu build, configured like this:
setarch 
i486 ./configure --prefix=/usr --disable-gtk --enable-virglrenderer 
--enable-sdl 
\ --with-sdlabi=2.0 --audio-drv-list=alsa,oss --host-cc=/opt/gcc49/bin/gcc 
\ --enable-opengl --extra-cflags="-I/usr/X11R7/include -O3 -march=i686 
\ -mtune=native -m32 -Wno-maybe-uninitialized -Wno-nested-externs 
\ -Wno-implicit-function-declaration" --disable-werror

for qemu-system-ppc -M mac99 'info pci' shows:

qemu-system-ppc -monitor stdio -vga std -M mac99
QEMU 2.12.91 monitor - type 'help' for more information
(qemu) info pci
  Bus  0, device  11, function 0:
Host bridge: PCI device 106b:001f
  id ""
  Bus  0, device  12, function 0:
Class 65280: PCI device 106b:0022
  BAR0: 32 bit memory at 0x8000 [0x8007].
  id ""
  Bus  0, device  13, function 0:
USB controller: PCI device 106b:003f
  IRQ 28.
  BAR0: 32 bit memory at 0x8008 [0x800800ff].
  id ""
  Bus  0, device  14, function 0:
VGA controller: PCI device 1234:
  BAR0: 32 bit prefetchable memory at 0x8100 [0x81ff].
  BAR2: 32 bit memory at 0x8200 [0x82000fff].
  BAR6: 32 bit memory at 0x8201 [0x8201].
  id ""
  Bus  0, device  15, function 0:
Ethernet controller: PCI device 10ec:8029
  IRQ 30.
  BAR0: I/O at 0x1000 [0x10ff].
  BAR6: 32 bit memory at 0x8204 [0x8207].
  id ""
  Bus  0, device  14, function 0:
Host bridge: PCI device 106b:001e
  id ""
  Bus  0, device  11, function 0:
Host bridge: PCI device 106b:0020
  id ""
(qemu) 

Last two devices seems strange .

Also, mouse seems to be confused, try  finnix-ppc-110.iso (it enables gpm on 
startup, start like qemu-system-ppc -monitor stdio -M mac99 -cdrom 
~/finnix-ppc-110.iso and try to move mouse inside qemu window. It feels like 
keyboard got some mouseclicks too? or mouse movement generates mouse button 
clicks, too) or http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/ ->
  
[   ]  lubuntu-16.04-desktop-powerpc.iso   (but you must wait for nearly 10 min 
until it finishes booting)  
   

Re: [Qemu-devel] [Bug 1769189] Re: Issue with qemu 2.12.0 + SATA

[Andrew Randrianasulu]

For me issue was fixed with «[PATCH 2/3] ahci: fix PxCI register race»

I additionally patched my qemu build with "[PATCH] e1000e: Do not auto-clear 
ICR 
bits which aren't set in EIAC" - so new network adapter for q35 machine works 
with KDE Neon liveDVD for example 

[Qemu-devel] [Bug 1769189] Re: Issue with qemu 2.12.0 + SATA

[Andrew Randrianasulu]

I think I was hit with very same bug.

I did bisect with 2.11.0 as good point and 2.12.0 as bad point.

configure was 

setarch 
i486 ./configure --prefix=/usr --disable-gtk --enable-virglrenderer 
--enable-sdl --with-sdlabi=2.0 --audio-drv-list=alsa,oss 
--host-cc=/opt/gcc49/bin/gcc --enable-opengl 
--extra-cflags="-I/usr/X11R7/include -O3 -march=i686 -mtune=native -m32 
-Wno-maybe-uninitialized -Wno-nested-externs 
-Wno-implicit-function-declaration" --disable-werror 
--target-list="x86_64-softmmu"

and launch command

x86_64-softmmu/qemu-system-x86_64 -cdrom 
~/Downloads/ISO/slax-English-US-7.0.8-x86_64.iso -enable-kvm -m 1G -M q35




git bisect bad
66eb7825d0bd84a870a054fb208fe765317109fa is the first bad commit
commit 66eb7825d0bd84a870a054fb208fe765317109fa
Author: Pavel Dovgalyuk 
Date:   Tue Feb 27 12:53:05 2018 +0300

replay: avoid recursive call of checkpoints

This patch adds a flag which denies recursive call of replay_checkpoint
function. Checkpoints may be accompanied by the hardware events. When event
is processed, virtual device may invoke timer modification functions that
also invoke the checkpoint function. This leads to infinite loop.

Signed-off-by: Pavel Dovgalyuk 
Message-Id: <20180227095305.1060.56463.stgit@pasha-VirtualBox>
Signed-off-by: Paolo Bonzini 
Signed-off-by: Pavel Dovgalyuk 

:04 04 f8d1eb18d3a8fcd0df0329e6b899a515e4b0e16e 
a286be2d590b42b15f9facf033348ee37c460d25 M  replay

-

git bisect log
git bisect start
# good: [0a0dc59d27527b78a195c2d838d28b7b49e5a639] Update version for v2.11.0 
release
git bisect good 0a0dc59d27527b78a195c2d838d28b7b49e5a639
# bad: [4743c23509a51bd4ee85cc272287a41917d1be35] Update version for v2.12.0 
release
git bisect bad 4743c23509a51bd4ee85cc272287a41917d1be35
# skip: [db57d7a3c284db2315d92f55962597cc7276579a] wdt_ib700-test: Drop 
dependence on global_qtest
git bisect skip db57d7a3c284db2315d92f55962597cc7276579a
# good: [539022dd6089cdef36589d608ed63cbdaacfd71f] chardev: Clean up previous 
patch indentation
git bisect good 539022dd6089cdef36589d608ed63cbdaacfd71f
# good: [9db0855e8501365334e859370800c240d25322a2] Merge remote-tracking 
branch 'remotes/pmaydell/tags/pull-target-arm-20180301' into staging
git bisect good 9db0855e8501365334e859370800c240d25322a2
# good: [a57946ff2acb9c0d95c9f127914540586b0b8c21] Merge remote-tracking 
branch 'remotes/awilliam/tags/vfio-update-20180313.0' into staging
git bisect good a57946ff2acb9c0d95c9f127914540586b0b8c21
# bad: [211d6260208d079429fd0d447b86ff480d0524ca] Merge remote-tracking 
branch 'remotes/kevin/tags/for-upstream' into staging
git bisect bad 211d6260208d079429fd0d447b86ff480d0524ca
# bad: [09b68dab5a11e8657119bc1d2ab18e98a70530ed] vhdx: Support .bdrv_co_create
git bisect bad 09b68dab5a11e8657119bc1d2ab18e98a70530ed
# bad: [3788c7b6e56fa34ee2a73e41706eb2a2447ba75a] Merge remote-tracking 
branch 'remotes/bonzini/tags/for-upstream' into staging
git bisect bad 3788c7b6e56fa34ee2a73e41706eb2a2447ba75a
# good: [63f01a74aeeb9c4fb39e2b4100beb084f5c10c95] hw/isa/pc87312: Inherit from 
the abstract TYPE_ISA_SUPERIO
git bisect good 63f01a74aeeb9c4fb39e2b4100beb084f5c10c95
# good: [1a96e3c1e7dbb466a8c93743b8f5ae37cc023766] replay: fix processing async 
events
git bisect good 1a96e3c1e7dbb466a8c93743b8f5ae37cc023766
# good: [1a423896fa4fc2ea49c64e7a493d88a8b251950d] replay: don't destroy mutex 
at exit
git bisect good 1a423896fa4fc2ea49c64e7a493d88a8b251950d
# bad: [821c113033075d4f1b50966d92022a1064085422] scripts/replay-dump.py: 
replay 
log dumper
git bisect bad 821c113033075d4f1b50966d92022a1064085422
# good: [6dc0f5296359ff59c248215a965c8658dea9544b] replay: check return values 
of fwrite
git bisect good 6dc0f5296359ff59c248215a965c8658dea9544b
# bad: [66eb7825d0bd84a870a054fb208fe765317109fa] replay: avoid recursive call 
of checkpoints
git bisect bad 66eb7825d0bd84a870a054fb208fe765317109fa
# first bad commit: [66eb7825d0bd84a870a054fb208fe765317109fa] replay: avoid 
recursive call of checkpoints