From: David Gibson <david@gibson.dropbear.id.au>
To: Fabiano Rosas <farosas@linux.ibm.com>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
"Maxiwell S. Garcia" <maxiwell@linux.ibm.com>
Subject: Re: [PATCH] target/ppc: fix memory dump endianness in QEMU monitor
Date: Thu, 26 Dec 2019 12:54:25 +1100 [thread overview]
Message-ID: <20191226015425.GA4812@umbus.modem> (raw)
In-Reply-To: <8736d9g0w5.fsf@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]
On Tue, Dec 24, 2019 at 01:10:34PM -0300, Fabiano Rosas wrote:
> David Gibson <david@gibson.dropbear.id.au> writes:
>
> >> It looks like the hflags MSR_LE is being updated correctly with TCG. But
> >> with KVM we only touch it on system_reset
> >
> > Ah.. right. I think to fix that we'd want an hreg_compute_hflags() at
> > the end of sucking the state out of KVM.
> >
>
> Hm.. The hflags is a TCG thing that does not get used with KVM at all,
> except for that one bit in the monitor disas function. I'd rather keep
> it completely out of kvm_enabled code.
That's a fair point.
It doesn't look like there's any reason ppc_tr_init_disas_context()
couldn't initialize ctx->le_mode directly from the MSR rather than
hflags anyway. If we do that, we should again be able to remove the
LE bit from hflags entirely. I think that's the way to go.
>
> Couldn't we perhaps make it conditional on the acceleration type?
> Using kvm_enabled() or some ifdef.
>
> Thanks
>
> >> (and possibly h_cede? I don't
> >> know if it is QEMU who handles it).
> >
> > It's KVM. If we used the qemu one it would add an awful lot of
> > latency to cedes.
> >>
> >> So I would let hflags be.
> >>
> >>
> >> ... Actually, I don't really know the purpose of hflags. It comes from:
> >>
> >> commit 3f3373166227b13e762e20d2fb51eadfa6a2d653
> >> Author: Fabrice Bellard <fabrice@bellard.org>
> >> Date: Wed Aug 20 23:02:09 2003 +0000
> >>
> >> pop ss, mov ss, x and sti disable irqs for the next instruction -
> >> began dispatch optimization by adding new x86 cpu 'hidden' flags
> >>
> >>
> >> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@372 c046a42c-6fe2-441c-8c8c-71466251a162
> >>
> >> Could any one clarify that?
> >
> > Not really. It's really, really old, in the cruft bits of TCG I don't
> > much understand.
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2019-12-26 1:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-19 16:38 [PATCH] target/ppc: fix memory dump endianness in QEMU monitor Maxiwell S. Garcia
2019-12-23 6:30 ` David Gibson
2019-12-23 21:35 ` Maxiwell S. Garcia
2019-12-24 5:10 ` David Gibson
2019-12-23 23:27 ` Fabiano Rosas
2019-12-24 5:19 ` David Gibson
2019-12-24 16:10 ` Fabiano Rosas
2019-12-26 1:54 ` David Gibson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191226015425.GA4812@umbus.modem \
--to=david@gibson.dropbear.id.au \
--cc=farosas@linux.ibm.com \
--cc=maxiwell@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).