[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 0/5] memattrs: target/arm: add user-defined and requester
From: |
Joe Komlodi |
Subject: |
Re: [RFC PATCH 0/5] memattrs: target/arm: add user-defined and requester ID memattrs |
Date: |
Thu, 29 Feb 2024 09:15:43 -0800 |
On Thu, Feb 29, 2024 at 1:57 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Thu, 29 Feb 2024 at 04:52, Joe Komlodi <komlodi@google.com> wrote:
> > On Wed, Feb 28, 2024 at 6:21 AM Peter Maydell <peter.maydell@linaro.org>
> > wrote:
> > > So as far as I can see, this patchset defines a bunch of mechanism,
> > > but no actual users: no device looks at these new memattrs, no board
> > > code sets the properties. I don't really want to add this without
> > > an upstream usecase for it.
> >
> > Yeah, I believe the current use-cases for this series are mostly downstream.
> > It's possible that there's an upstream device that might benefit from
> > it, but I'm not aware of one.
> >
> > Is the concern the usefulness of the series, or the worry about it
> > bit-rotting?
> > If it's the latter, would a qtest be alright to make sure it doesn't rot?
>
> My main issues are:
> * it's hard to review design without the uses of the code
> * it's extra complexity and maintenance burden that we don't
> need (upstream): accepting the patches gives upstream extra
> work to deal with into the future with no benefit to us
> * dead code is code that typically we would remove
> * we end up with something we can't refactor or clean up
> or change because the only reason we have it is for code
> that we don't have any visibility into: effectively it
> becomes an API for us that we can't change, which is not
> something QEMU does except for specific well defined API
> surfaces (QMP, plugins, etc)
>
> Our usual approach is "submit the patches that add the new core
> feature/mechanism along with the patches that add the new
> device/board/etc that uses it". Compare the recent patches
> also from Google for the ITS and SMMU that try to add hooks
> that aren't needed by anything in upstream QEMU:
> 20240221171716.1260192-1-nabihestefan@google.com/20240221171716.1260192-3-nabihestefan@google.com/">https://patchew.org/QEMU/20240221171716.1260192-1-nabihestefan@google.com/20240221171716.1260192-3-nabihestefan@google.com/
> 20240221173325.1494895-1-nabihestefan@google.com/20240221173325.1494895-3-nabihestefan@google.com/">https://patchew.org/QEMU/20240221173325.1494895-1-nabihestefan@google.com/20240221173325.1494895-3-nabihestefan@google.com/
> -- we rejected those for the same reason.
Makes sense!
Thanks for taking the time to look over them.
- Joe
>
> thanks
> -- PMM
- [RFC PATCH 0/5] memattrs: target/arm: add user-defined and requester ID memattrs, Joe Komlodi, 2024/02/27
- [RFC PATCH 1/5] target/arm: Add requester ID to memattrs, Joe Komlodi, 2024/02/27
- [RFC PATCH 3/5] memattrs: Add user-defined attribute, Joe Komlodi, 2024/02/27
- [RFC PATCH 4/5] target/arm: Add user-defined memattrs, Joe Komlodi, 2024/02/27
- [RFC PATCH 2/5] memattrs: Fix target_tlb_bit whitespace, Joe Komlodi, 2024/02/27
- [RFC PATCH 5/5] hw/pci: Add user-defined memattrs, Joe Komlodi, 2024/02/27
- Re: [RFC PATCH 0/5] memattrs: target/arm: add user-defined and requester ID memattrs, Peter Maydell, 2024/02/28