public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Harsh Prateek Bora <harshpb@linux.ibm.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"BALATON Zoltan" <balaton@eik.bme.hu>,
	"Glenn Miles" <milesg@linux.ibm.com>,
	"Chinmay Rath" <rathc@linux.ibm.com>
Cc: qemu-devel@nongnu.org, Anton Johansson <anjo@rev.ng>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	kvm@vger.kernel.org, qemu-ppc@nongnu.org,
	Pierrick Bouvier <pierrick.bouvier@linaro.org>
Subject: Re: [PATCH 5/8] target/ppc/mmu: Replace legacy ld/st_phys() -> address_space_ld/st()
Date: Wed, 22 Apr 2026 12:42:39 +0530	[thread overview]
Message-ID: <61318a9d-578d-438c-ac76-e7579f0eb743@linux.ibm.com> (raw)
In-Reply-To: <d64dff93-7129-4c39-bf9f-d2a8cf2ee4fb@linaro.org>



On 19/04/26 9:40 pm, Philippe Mathieu-Daudé wrote:
> On 19/3/26 13:59, BALATON Zoltan wrote:
>> On Thu, 19 Mar 2026, Philippe Mathieu-Daudé wrote:
>>> Prefer the address_space_ld/st API over the legacy ld_phys()
>>> because it allow checking for bus access fault.
>>>
>>> This code however doesn't check for fault, so we simply inline
>>> the calls (not specifying any memory transaction attribute nor
>>> expecting transation result) per the definition in
>>> "system/memory_ldst_phys_endian.h.inc":

Nit: "include/system/memory_ldst_phys_endian.h.inc"

>>
>> Recently when trying to remove _nomigrate memory region functions I 
>> was told if some convenience function has more than 1 use it's 
>> probably worth to keep it. This looks like similar case even more so 
>> as the replacement is unnecessarily more complicated. So what's the 
>> problem with ld_phys in the first place and why do you want to replace 
>> it with a less convenient function? If there's a reason maybe say that 
>> in the commit message.
> 
> We want to remove the legacy API because it does not "allow checking
> for bus access fault." The cases where we can safely ignore it are
> rare, and often ignoring it led to subtle bugs.

It would be nice to have an ack from BALATON or Glenn as well since rest 
of the patches are specific to pegasos/ppc32, although no funtional 
change intended here.

If we do not have any further comments from them/others, could you
please post v2 addressing the comment in patch 2/8 reg keeping 
declaration within !CONFIG_USER_ONLY block? It  could be moved to one of 
the existing block as well.

Thanks
Harsh

  reply	other threads:[~2026-04-22  7:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19 11:19 [PATCH 0/8] target/ppc: Forbid to use legacy ldst_phys() API Philippe Mathieu-Daudé
2026-03-19 11:19 ` [PATCH 1/8] hw/ppc/spapr: Un-inline rtas_load/store() helpers Philippe Mathieu-Daudé
2026-04-20  6:45   ` Harsh Prateek Bora
2026-03-19 11:19 ` [PATCH 2/8] target/ppc: Factor common ppc_load_epr() helper out Philippe Mathieu-Daudé
2026-04-20  6:46   ` Harsh Prateek Bora
2026-03-19 11:19 ` [PATCH 3/8] target/ppc/mmu: Remove unused hash32_store_hpte() helpers Philippe Mathieu-Daudé
2026-04-20  6:51   ` Harsh Prateek Bora
2026-03-19 11:19 ` [PATCH 4/8] target/ppc/mmu: Restrict hash32_load_hpte() helpers scope Philippe Mathieu-Daudé
2026-04-20  6:55   ` Harsh Prateek Bora
2026-03-19 11:19 ` [PATCH 5/8] target/ppc/mmu: Replace legacy ld/st_phys() -> address_space_ld/st() Philippe Mathieu-Daudé
2026-03-19 12:59   ` BALATON Zoltan
2026-04-19 16:10     ` Philippe Mathieu-Daudé
2026-04-22  7:12       ` Harsh Prateek Bora [this message]
2026-04-22 12:43         ` Miles Glenn
2026-03-19 11:19 ` [PATCH 6/8] hw/ppc/pegasos: Introduce rtas_ldl() / rtas_stl() helpers Philippe Mathieu-Daudé
2026-03-19 11:19 ` [PATCH 7/8] hw/ppc/pegasos: Replace legacy ld/st_phys() -> address_space_ld/st() Philippe Mathieu-Daudé
2026-03-19 11:19 ` [PATCH 8/8] configs/targets: Restrict the legacy ldst_phys() API on PPC Philippe Mathieu-Daudé
2026-04-19 16:11 ` [PATCH 0/8] target/ppc: Forbid to use legacy ldst_phys() API Philippe Mathieu-Daudé
2026-04-22  5:34 ` Chinmay Rath
2026-04-22 12:44 ` Miles Glenn

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=61318a9d-578d-438c-ac76-e7579f0eb743@linux.ibm.com \
    --to=harshpb@linux.ibm.com \
    --cc=anjo@rev.ng \
    --cc=balaton@eik.bme.hu \
    --cc=kvm@vger.kernel.org \
    --cc=milesg@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=pierrick.bouvier@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rathc@linux.ibm.com \
    /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