Review Request 75035: [mesos-build] install glibc.i686 on centos-7 to get an ELF interpreter
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75035/ --- Review request for mesos and Benjamin Mahler. Repository: mesos Description --- It seems that the extended BPF header files are available on the arm/v8 image and not the amd64 image for some reason. This review is a proposal for trying to run the arm64 image on the host x86 platform and installing an elf interpreter so that we can get our hands on the ebpf headers in centos7 Diffs - support/mesos-build/centos-7.dockerfile c75c5b61de0f76b4e02a083ae9b6b8d88e1e6612 Diff: https://reviews.apache.org/r/75035/diff/1/ Testing --- Thanks, Jason Zhou
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org2024/06/06 15:14:49 Modified files: usr.bin/ssh: sshd_config.5 Log message: escape the final dot at eol in "e.g." to avoid double spacing;
Re: Problem building cmake-core on FreeBSD 13.3
On Wed, Jun 5, 2024 at 6:22 AM Olivier wrote:
>
> Hi,
>
> I have a system that I try to upgrade from 13.2 to 13.3
>
> FreeBSD fbsd35.cs.ait.ac.th 13.3-RELEASE-p2 FreeBSD 13.3-RELEASE-p2
> releng/13.3-n257433-be4f1894ef39 GENERIC amd64
>
> When making cmake-core, I get the following error:
>
> -- Found JsonCpp: /usr/local/lib/libjsoncpp.so (found suitable version
> "1.9.5", minimum required is "1.6.0")
> -- Could NOT find LibUV: Found unsuitable version "1.16.1", but required is
> at least "1.28.0" (found /usr/local/lib/libuv.so)
> CMake Error at Source/Modules/CMakeBuildUtilities.cmake:332 (message):
> CMAKE_USE_SYSTEM_LIBUV is ON but a libuv is not found!
> Call Stack (most recent call first):
> CMakeLists.txt:441 (include)
>
>
> -- Configuring incomplete, errors occurred!
> -
> Error when bootstrapping CMake:
> Problem while running initial CMake
> -
> ===> Script "configure" failed unexpectedly.
> Please report the problem to k...@freebsd.org [maintainer] and attach the
> "/usr/ports/devel/cmake-core/work/cmake-3.28.3/config.log" including the
> output of the failure of your make command. Also, it might be a good idea to
> provide an overview of all packages installed on your system (e.g. a
> /usr/local/sbin/pkg-static info -g -Ea).
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/devel/cmake-core
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/devel/cmake-core
>
> I checked that LibUV is at the right version:
>
> pkg info |grep -i libuv
> libuv-1.48.0 Multi-platform support library with a focus on
> asynchronous I/O
>
> There is no /usr/ports/devel/cmake-core/work/cmake-3.28.3/config.log
> but I have attached the packages list and
> ./work/cmake-3.28.3/CMakeFiles/CMakeError.log
>
> Best regards,
>
> Olivier
> --
This looks like bug 272895 [1].
You probably still have some leftover bits from an old libuv
installation on your system. If you have any
${LOCALBASE}/include/uv-\*.h files, please remove them manually. The
headers are now in the ${LOCALBASE}/include/uv directory. There should
still be a ${LOCALBASE}/include/uv.h, however.
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272895
- Jason
[jira] [Resolved] (SOLR-17317) JAX-RS v2 APIs return XML when wt=json specified
[ https://issues.apache.org/jira/browse/SOLR-17317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski resolved SOLR-17317. Fix Version/s: main (10.0) 9.7 Resolution: Fixed > JAX-RS v2 APIs return XML when wt=json specified > > > Key: SOLR-17317 > URL: https://issues.apache.org/jira/browse/SOLR-17317 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: v2 API >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Minor > Fix For: main (10.0), 9.7 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > A mailing list user recently pointed out that certain JAX-RS v2 APIs return > XML content when "wt=json" is specified! The cause is an embarrassing > oversight in "V2ApiUtils.getMediaTypeFromWtParam": a switch-case statement > there accidentally omits "json" from its list of supported "wt" values. > We should add the missing branch of the switch-case block, and validate that > v2 APIs now respond correctly when wt=json is specified. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: CI build failures
> I recall getting a direct email to me if I contributed a > change to a CI failure. I would like this. I would also like a dev > list email periodically (weekly?) listing the CI job status +1 to any effort that aims to summarize "builds@". Even for folks that check "builds@" regularly it can be hard to catch the "signal" through all the noise. "builds@" sent out so much (~65 failure/unstable emails this week, with 11 yesterday alone!) that it's all too easy to miss a failure that's new, or potentially related to something I changed recently. That's why Fucit is so valuable for us IMO - aggregation. It's giving us information at a glance that you could otherwise only get by slogging through 50-70 emails. Any other creative ways we can find to aggregate or digest that "build@" content is going to be helpful IMO. > You mention “PR validation doesn’t run BATS tests”…. Maybe it should? +1 to this as well. I don't have opinions on the specific form of that additional PR validation (e.g. BATS vs docker). But the general idea of trading a bit of speed on our PR checks for additional validation/coverage is a good one IMO. Jason On Thu, Jun 6, 2024 at 9:32 AM David Smiley wrote: > > We could add (yet) another Github workflow validation. Or maybe take > the Docker one, which looks at certain paths (including bin/solr), and > generalizes to be not just testing docker but also running BATS > integration tests. Then think of this as the "integration test" > build. The "paths" it looks at could be expanded to include some of > the Java source CLI patterns so this runs in more cases that are > likely to be impacted. > > I'm slightly reluctant to take the Crave build and slow it down to run > those integration tests that run serially. It's amazing, particularly > when working locally, to get fast feedback on all Java based tests. > Admittedly it's not an either-or; it's a matter of indicating the > desired targets in the build, so I shouldn't be reluctant here. > Anyway, I'm more keen to expand the scope of the Docker build. > > On Thu, Jun 6, 2024 at 9:17 AM Eric Pugh > wrote: > > > > I think a weekly heads up would be great to have. > > > > You mention “PR validation doesn’t run BATS tests”…. Maybe it should? > > We’ve had a lot of churn in the CLI, and we’ll probably continue to have > > that till 10x comes out, so that would be a nice check. Plus, if we add > > more integration style BATS tests, why not have them be run on the PR’s? > > > > > On May 31, 2024, at 11:40 AM, David Smiley wrote: > > > > > > I'm concerned that too few people look at the bui...@solr.apache.org > > > From time to time I go look but we have no notifications other than > > > emailing that list. > > > > > > If hypothetically nobody looked, we might as well not have CI at all; > > > we'd only have PR based validation. We'd lose out on historic test > > > failure tracking and detection of introducing a problem that got > > > merged anyway. PR validation doesn't run BATS tests or "Nightly" > > > tests. > > > > > > Long ago, I recall getting a direct email to me if I contributed a > > > change to a CI failure. I would like this. I would also like a dev > > > list email periodically (weekly?) listing the CI job status. > > > > > > Any opinions on what to do here? > > > > > > ~ David Smiley > > > Apache Lucene/Solr Search Developer > > > http://www.linkedin.com/in/davidwsmiley > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > ___ > > Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | > > http://www.opensourceconnections.com > > <http://www.opensourceconnections.com/> | My Free/Busy > > <http://tinyurl.com/eric-cal> > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > This e-mail and all contents, including attachments, is considered to be > > Company Confidential unless explicitly stated otherwise, regardless of > > whether attachments are marked as such. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
Re: Changes in JAX-RS APIs mean may need to "gradlew clean" ?
It worked! There's a PR here with the fix: https://github.com/apache/solr/pull/2502. Take a look when you get a chance and let me know what you think! (I haven't created a JIRA ticket, since it's a minor change to our build. If anyone would prefer a JIRA ticket to document this beyond what this dev-thread and Github PR provide, let me know.) Best, Jason On Thu, Jun 6, 2024 at 7:05 AM Jason Gerlowski wrote: > > Yeah, this is definitely a pain from time to time. > > For anyone who hasn't hit this, steps to reproduce are: > > 1. Start on a branch that has a new JAX-RS-annotated interface in > Solr's 'api' module. > 2. Any gradle task that compiles SolrJ will build Solr's OpenAPI spec, > generate SolrRequest implementations from that spec, and add them to > solrj's build directory as a part of its "source set". These > generated classes often reference 'model' classes (e.g. request or > response POJOs) that exist on the current branch, but may not be on > other branches. > 3. Switch to a new branch, which lacks the new JAX-RS API. > 4. If solrj is compiled without running "clean" first, the previously > generated SolrRequest implementations will fail to compile (because > the request/response POJOs they rely on are missing). > > In terms of *when* this happens, I often see it when changing from a > PR-branch to main. Though you can also see it going from 'main' to > 'branch_9x', if 'main' has a JAX-RS API that hasn't been backported > yet. > > I've been a little despairing in the past about fixing this- I know it > should be done, but my gradle knowledge is pretty lacking. Though I > notice in writing this email that the 'openApiGenerate' task itself > has a few options that might fix this without any broader gradle > changes, particularly the "cleanupOutput" and "skipOverwrite" options. > I'll try playing with those a bit and report back if there's any > promise. > > Best, > > Jason > > > On Tue, Jun 4, 2024 at 6:52 PM David Smiley wrote: > > > > I noticed some generated source files, and in particular > > solr/solrj/build/generated/src/main/java/org/apache/solr/client/solrj/request/FileStoreApi.java > > that suddenly had a compilation issue. This is almost certainly due > > to the API evolving, and SOLR-17302 in particular. Just do "gradlew > > clean" to start fresh. I've hit this a couple times for different > > specific API issues over some months. > > > > Still... should the build be smart enough to avoid this? For example > > if the generator is blind to the output directory's contents, we may > > as well clean the generated directory fully first. On the other hand, > > maybe it smartly recognizes existing generated stuff and can tell that > > it doesn't need to re-generate (like javac). > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
Re: Can't Empty Inbox that is Over quota
I am getting this error imap-login: Disconnected: Connection closed: SSL_accept() failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown: SSL alert number 46 (no auth attempts in 0 secs): user=<>, rip=69.142.122.175, lip=209.160.65.133, TLS handshaking: SSL_accept() failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown: SSL alert number 46, session= J I tried sending the results of doveconf -n. But the resulting message I too big and waits monitor review > On Jun 6, 2024, at 7:29 AM, Benny Pedersen via dovecot > wrote: > > Jason Hirsh via dovecot skrev den 2024-06-06 03:20: > >> Is there anyway I can remove Dovecot from my server and reinstalll it? It >> is so messed up I don’t care about losing data > > reinstall will make the same install problem fails > > i often joke about precompiled problems :) > > more help show logs > > and also doveconf -n > > ___ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-le...@dovecot.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Changes in JAX-RS APIs mean may need to "gradlew clean" ?
Yeah, this is definitely a pain from time to time. For anyone who hasn't hit this, steps to reproduce are: 1. Start on a branch that has a new JAX-RS-annotated interface in Solr's 'api' module. 2. Any gradle task that compiles SolrJ will build Solr's OpenAPI spec, generate SolrRequest implementations from that spec, and add them to solrj's build directory as a part of its "source set". These generated classes often reference 'model' classes (e.g. request or response POJOs) that exist on the current branch, but may not be on other branches. 3. Switch to a new branch, which lacks the new JAX-RS API. 4. If solrj is compiled without running "clean" first, the previously generated SolrRequest implementations will fail to compile (because the request/response POJOs they rely on are missing). In terms of *when* this happens, I often see it when changing from a PR-branch to main. Though you can also see it going from 'main' to 'branch_9x', if 'main' has a JAX-RS API that hasn't been backported yet. I've been a little despairing in the past about fixing this- I know it should be done, but my gradle knowledge is pretty lacking. Though I notice in writing this email that the 'openApiGenerate' task itself has a few options that might fix this without any broader gradle changes, particularly the "cleanupOutput" and "skipOverwrite" options. I'll try playing with those a bit and report back if there's any promise. Best, Jason On Tue, Jun 4, 2024 at 6:52 PM David Smiley wrote: > > I noticed some generated source files, and in particular > solr/solrj/build/generated/src/main/java/org/apache/solr/client/solrj/request/FileStoreApi.java > that suddenly had a compilation issue. This is almost certainly due > to the API evolving, and SOLR-17302 in particular. Just do "gradlew > clean" to start fresh. I've hit this a couple times for different > specific API issues over some months. > > Still... should the build be smart enough to avoid this? For example > if the generator is blind to the output directory's contents, we may > as well clean the generated directory fully first. On the other hand, > maybe it smartly recognizes existing generated stuff and can tell that > it doesn't need to re-generate (like javac). > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
[PATCH] remoteproc: mediatek: Increase MT8188 SCP core0 DRAM size
From: Jason Chen
Increase MT8188 SCP core0 DRAM size for HEVC driver.
Signed-off-by: Jason Chen
---
drivers/remoteproc/mtk_scp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index b885a9a041e4..2119fc62c3f2 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -1390,7 +1390,7 @@ static const struct mtk_scp_sizes_data default_scp_sizes
= {
};
static const struct mtk_scp_sizes_data mt8188_scp_sizes = {
- .max_dram_size = 0x50,
+ .max_dram_size = 0x80,
.ipi_share_buffer_size = 600,
};
--
2.34.1
Review Request 75032: install openjdk 11 on ubuntu 20.04
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75032/ --- Review request for mesos and Benjamin Mahler. Repository: mesos Description --- install openjdk 11 on ubuntu 20.04 Our reviewbot is running into issues where their java 11 installation is missing javac and configure.ac cannot run properly, this fixes that issue Diffs - support/docker-build.sh 4f4019001755082c8dcbea5cb0043363940d383c Diff: https://reviews.apache.org/r/75032/diff/1/ Testing --- Thanks, Jason Zhou
Re: [PATCH] tools/virtio: Use the __GFP_ZERO flag of kmalloc to complete the memory initialization.
On Wed, Jun 5, 2024 at 9:56 PM cuitao wrote:
>
> Use the __GFP_ZERO flag of kmalloc to initialize memory while allocating it,
> without the need for an additional memset call.
>
> Signed-off-by: cuitao
> ---
> tools/virtio/linux/kernel.h | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/tools/virtio/linux/kernel.h b/tools/virtio/linux/kernel.h
> index 6702008f7f5c..9e401fb7c215 100644
> --- a/tools/virtio/linux/kernel.h
> +++ b/tools/virtio/linux/kernel.h
> @@ -66,10 +66,7 @@ static inline void *kmalloc_array(unsigned n, size_t s,
> gfp_t gfp)
>
> static inline void *kzalloc(size_t s, gfp_t gfp)
> {
> - void *p = kmalloc(s, gfp);
> -
> - memset(p, 0, s);
> - return p;
> + return kmalloc(s, gfp | __GFP_ZERO);
> }
>
> static inline void *alloc_pages_exact(size_t s, gfp_t gfp)
> --
> 2.25.1
>
Does this really work?
extern void *__kmalloc_fake, *__kfree_ignore_start, *__kfree_ignore_end;
static inline void *kmalloc(size_t s, gfp_t gfp)
{
if (__kmalloc_fake)
return __kmalloc_fake;
return malloc(s);
}
Thanks
Re: [PATCH net-next V2] virtio-net: synchronize operstate with admin state on up/down
On Fri, May 31, 2024 at 8:18 AM Jason Wang wrote:
>
> On Thu, May 30, 2024 at 9:09 PM Michael S. Tsirkin wrote:
> >
> > On Thu, May 30, 2024 at 06:29:51PM +0800, Jason Wang wrote:
> > > On Thu, May 30, 2024 at 2:10 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Thu, May 30, 2024 at 11:20:55AM +0800, Jason Wang wrote:
> > > > > This patch synchronize operstate with admin state per RFC2863.
> > > > >
> > > > > This is done by trying to toggle the carrier upon open/close and
> > > > > synchronize with the config change work. This allows propagate status
> > > > > correctly to stacked devices like:
> > > > >
> > > > > ip link add link enp0s3 macvlan0 type macvlan
> > > > > ip link set link enp0s3 down
> > > > > ip link show
> > > > >
> > > > > Before this patch:
> > > > >
> > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > > > mode DEFAULT group default qlen 1000
> > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > > ..
> > > > > 5: macvlan0@enp0s3: mtu 1500
> > > > > qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > > >
> > > > > After this patch:
> > > > >
> > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > > > mode DEFAULT group default qlen 1000
> > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > > ...
> > > > > 5: macvlan0@enp0s3: mtu
> > > > > 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default
> > > > > qlen 1000
> > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > > >
> > > > > Cc: Venkat Venkatsubra
> > > > > Cc: Gia-Khanh Nguyen
> > > > > Reviewed-by: Xuan Zhuo
> > > > > Acked-by: Michael S. Tsirkin
> > > > > Signed-off-by: Jason Wang
> > > > > ---
> > > > > Changes since V1:
> > > > > - rebase
> > > > > - add ack/review tags
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > ---
> > > > > drivers/net/virtio_net.c | 94
> > > > > +++-
> > > > > 1 file changed, 63 insertions(+), 31 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > > index 4a802c0ea2cb..69e4ae353c51 100644
> > > > > --- a/drivers/net/virtio_net.c
> > > > > +++ b/drivers/net/virtio_net.c
> > > > > @@ -433,6 +433,12 @@ struct virtnet_info {
> > > > > /* The lock to synchronize the access to refill_enabled */
> > > > > spinlock_t refill_lock;
> > > > >
> > > > > + /* Is config change enabled? */
> > > > > + bool config_change_enabled;
> > > > > +
> > > > > + /* The lock to synchronize the access to config_change_enabled
> > > > > */
> > > > > + spinlock_t config_change_lock;
> > > > > +
> > > > > /* Work struct for config space updates */
> > > > > struct work_struct config_work;
> > > > >
> > > >
> > > >
> > > > But we already have dev->config_lock and dev->config_enabled.
> > > >
> > > > And it actually works better - instead of discarding config
> > > > change events it defers them until enabled.
> > > >
> > >
> > > Yes but then both virtio-net driver and virtio core can ask to enable
> > > and disable and then we need some kind of synchronization which is
> > > non-trivial.
> >
> > Well for core it happens on bring up path before driver works
> > and later on tear down after it is gone.
> > So I do not think they ever do it at the same time.
>
> For example, there could be a suspend/resume when the admin state is down.
>
> >
> >
> > > And device enabling on the core is different from bringing the device
> > > up in the networking subsystem. Here we just delay to deal with the
> > > config change interrupt on ndo_open(). (E.g try to ack announce is
> > > meaningless when the device is down).
> > >
> > > Thanks
> >
> > another thing is that it is better not to re-read all config
> > on link up if there was no config interrupt - less vm exits.
>
> Yes, but it should not matter much as it's done in the ndo_open().
Michael, any more comments on this?
Please confirm if this patch is ok or not. If you prefer to reuse the
config_disable() I can change it from a boolean to a counter that
allows to be nested.
Thanks
>
> Thanks
>
> >
> > --
> > MST
> >
Re: [EXTERNAL] Re: [PATCH] vdpa: Add support for no-IOMMU mode
On Tue, Jun 4, 2024 at 5:29 PM Srujana Challa wrote:
>
> > Subject: [EXTERNAL] Re: [PATCH] vdpa: Add support for no-IOMMU mode
> >
> > Prioritize security for external emails: Confirm sender and content safety
> > before clicking links or opening attachments
> >
> > --
> > On Thu, May 30, 2024 at 6:18 PM Srujana Challa
> > wrote:
> > >
> > > This commit introduces support for an UNSAFE, no-IOMMU mode in the
> > > vhost-vdpa driver. When enabled, this mode provides no device
> > > isolation, no DMA translation, no host kernel protection, and cannot
> > > be used for device assignment to virtual machines. It requires RAWIO
> > > permissions and will taint the kernel.
> > > This mode requires enabling the
> > "enable_vhost_vdpa_unsafe_noiommu_mode"
> > > option on the vhost-vdpa driver. This mode would be useful to get
> > > better performance on specifice low end machines and can be leveraged
> > > by embedded platforms where applications run in controlled environment.
> >
> > I wonder if it's better to do it per driver:
> >
> > 1) we have device that use its own IOMMU, one example is the mlx5 vDPA
> > device
> > 2) we have software devices which doesn't require IOMMU at all (but still
> > with
> > protection)
>
> If I understand correctly, you’re suggesting that we create a module parameter
> specific to the vdpa driver. Then, we can add a flag to the ‘struct
> vdpa_device’
> and set that flag within the vdpa driver based on the module parameter.
> Finally, we would use this flag to taint the kernel and go in no-iommu path
> in the vhost-vdpa driver?
If it's possible, I would like to avoid changing the vDPA core.
Thanks
> >
> > Thanks
> >
> > >
> > > Signed-off-by: Srujana Challa
> > > ---
> > > drivers/vhost/vdpa.c | 23 +++
> > > 1 file changed, 23 insertions(+)
> > >
> > > diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index
> > > bc4a51e4638b..d071c30125aa 100644
> > > --- a/drivers/vhost/vdpa.c
> > > +++ b/drivers/vhost/vdpa.c
> > > @@ -36,6 +36,11 @@ enum {
> > >
> > > #define VHOST_VDPA_IOTLB_BUCKETS 16
> > >
> > > +bool vhost_vdpa_noiommu;
> > > +module_param_named(enable_vhost_vdpa_unsafe_noiommu_mode,
> > > + vhost_vdpa_noiommu, bool, 0644);
> > > +MODULE_PARM_DESC(enable_vhost_vdpa_unsafe_noiommu_mode,
> > "Enable
> > > +UNSAFE, no-IOMMU mode. This mode provides no device isolation, no
> > > +DMA translation, no host kernel protection, cannot be used for device
> > > +assignment to virtual machines, requires RAWIO permissions, and will
> > > +taint the kernel. If you do not know what this is for, step away.
> > > +(default: false)");
> > > +
> > > struct vhost_vdpa_as {
> > > struct hlist_node hash_link;
> > > struct vhost_iotlb iotlb;
> > > @@ -60,6 +65,7 @@ struct vhost_vdpa {
> > > struct vdpa_iova_range range;
> > > u32 batch_asid;
> > > bool suspended;
> > > + bool noiommu_en;
> > > };
> > >
> > > static DEFINE_IDA(vhost_vdpa_ida);
> > > @@ -887,6 +893,10 @@ static void vhost_vdpa_general_unmap(struct
> > > vhost_vdpa *v, {
> > > struct vdpa_device *vdpa = v->vdpa;
> > > const struct vdpa_config_ops *ops = vdpa->config;
> > > +
> > > + if (v->noiommu_en)
> > > + return;
> > > +
> > > if (ops->dma_map) {
> > > ops->dma_unmap(vdpa, asid, map->start, map->size);
> > > } else if (ops->set_map == NULL) { @@ -980,6 +990,9 @@ static
> > > int vhost_vdpa_map(struct vhost_vdpa *v, struct vhost_iotlb *iotlb,
> > > if (r)
> > > return r;
> > >
> > > + if (v->noiommu_en)
> > > + goto skip_map;
> > > +
> > > if (ops->dma_map) {
> > > r = ops->dma_map(vdpa, asid, iova, size, pa, perm,
> > > opaque);
> > > } else if (ops->set_map) {
> > > @@ -995,6 +1008,7 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
> > struct vhost_iotlb *iotlb,
> > > return r;
> > > }
> > >
> > > +skip_map:
> > > if (!vdpa->use_va)
> > > atomic64_add(PFN_DOWN(size), >mm->pinned_vm);
> > >
> > > @@ -1298,6 +1312,7 @@ static int vhost_vdpa_alloc_domain(struct
> > vhost_vdpa *v)
> > > struct vdpa_device *vdpa = v->vdpa;
> > > const struct vdpa_config_ops *ops = vdpa->config;
> > > struct device *dma_dev = vdpa_get_dma_dev(vdpa);
> > > + struct iommu_domain *domain;
> > > const struct bus_type *bus;
> > > int ret;
> > >
> > > @@ -1305,6 +1320,14 @@ static int vhost_vdpa_alloc_domain(struct
> > vhost_vdpa *v)
> > > if (ops->set_map || ops->dma_map)
> > > return 0;
> > >
> > > + domain = iommu_get_domain_for_dev(dma_dev);
> > > + if ((!domain || domain->type == IOMMU_DOMAIN_IDENTITY) &&
> > > + vhost_vdpa_noiommu && capable(CAP_SYS_RAWIO)) {
> > > +
Re: [PATCH] vdpa: Add support for no-IOMMU mode
On Tue, Jun 4, 2024 at 7:55 PM Stefano Garzarella wrote:
>
> On Fri, May 31, 2024 at 10:26:31AM GMT, Jason Wang wrote:
> >On Thu, May 30, 2024 at 6:18 PM Srujana Challa wrote:
> >>
> >> This commit introduces support for an UNSAFE, no-IOMMU mode in the
> >> vhost-vdpa driver. When enabled, this mode provides no device isolation,
> >> no DMA translation, no host kernel protection, and cannot be used for
> >> device assignment to virtual machines. It requires RAWIO permissions
> >> and will taint the kernel.
> >> This mode requires enabling the "enable_vhost_vdpa_unsafe_noiommu_mode"
> >> option on the vhost-vdpa driver. This mode would be useful to get
> >> better performance on specifice low end machines and can be leveraged
> >> by embedded platforms where applications run in controlled environment.
> >
> >I wonder if it's better to do it per driver:
> >
> >1) we have device that use its own IOMMU, one example is the mlx5 vDPA device
> >2) we have software devices which doesn't require IOMMU at all (but
> >still with protection)
>
> It worries me even if the module parameter is the best thing.
> What about a sysfs entry?
Not sure, but VFIO uses a module parameter, and using sysfs requires
some synchronization. We need either disable the write when the device
is probed or allow change the value.
Thanks
>
> Thanks,
> Stefano
>
> >
> >Thanks
> >
> >>
> >> Signed-off-by: Srujana Challa
> >> ---
> >> drivers/vhost/vdpa.c | 23 +++
> >> 1 file changed, 23 insertions(+)
> >>
> >> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> >> index bc4a51e4638b..d071c30125aa 100644
> >> --- a/drivers/vhost/vdpa.c
> >> +++ b/drivers/vhost/vdpa.c
> >> @@ -36,6 +36,11 @@ enum {
> >>
> >> #define VHOST_VDPA_IOTLB_BUCKETS 16
> >>
> >> +bool vhost_vdpa_noiommu;
> >> +module_param_named(enable_vhost_vdpa_unsafe_noiommu_mode,
> >> + vhost_vdpa_noiommu, bool, 0644);
> >> +MODULE_PARM_DESC(enable_vhost_vdpa_unsafe_noiommu_mode, "Enable UNSAFE,
> >> no-IOMMU mode. This mode provides no device isolation, no DMA
> >> translation, no host kernel protection, cannot be used for device
> >> assignment to virtual machines, requires RAWIO permissions, and will taint
> >> the kernel. If you do not know what this is for, step away. (default:
> >> false)");
> >> +
> >> struct vhost_vdpa_as {
> >> struct hlist_node hash_link;
> >> struct vhost_iotlb iotlb;
> >> @@ -60,6 +65,7 @@ struct vhost_vdpa {
> >> struct vdpa_iova_range range;
> >> u32 batch_asid;
> >> bool suspended;
> >> + bool noiommu_en;
> >> };
> >>
> >> static DEFINE_IDA(vhost_vdpa_ida);
> >> @@ -887,6 +893,10 @@ static void vhost_vdpa_general_unmap(struct
> >> vhost_vdpa *v,
> >> {
> >> struct vdpa_device *vdpa = v->vdpa;
> >> const struct vdpa_config_ops *ops = vdpa->config;
> >> +
> >> + if (v->noiommu_en)
> >> + return;
> >> +
> >> if (ops->dma_map) {
> >> ops->dma_unmap(vdpa, asid, map->start, map->size);
> >> } else if (ops->set_map == NULL) {
> >> @@ -980,6 +990,9 @@ static int vhost_vdpa_map(struct vhost_vdpa *v, struct
> >> vhost_iotlb *iotlb,
> >> if (r)
> >> return r;
> >>
> >> + if (v->noiommu_en)
> >> + goto skip_map;
> >> +
> >> if (ops->dma_map) {
> >> r = ops->dma_map(vdpa, asid, iova, size, pa, perm, opaque);
> >> } else if (ops->set_map) {
> >> @@ -995,6 +1008,7 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
> >> struct vhost_iotlb *iotlb,
> >> return r;
> >> }
> >>
> >> +skip_map:
> >> if (!vdpa->use_va)
> >> atomic64_add(PFN_DOWN(size), >mm->pinned_vm);
> >>
> >> @@ -1298,6 +1312,7 @@ static int vhost_vdpa_alloc_domain(struct vhost_vdpa
> >> *v)
> >> struct vdpa_device *vdpa = v->vdpa;
> >> const struct vdpa_config_ops *ops = vdpa->config;
> >> struct device *dma_dev = vdpa_get_dma_dev(vdpa);
> >> + struct iommu_domain *domain;
> >> const struct bus_type *bus;
> >> int ret;
> >>
> >> @@ -1305,6 +1320,14 @@ static int vhost_vdpa_alloc_domain(struct
> >> vhost_vdpa *v)
> >> if (ops->set_map || ops->dma_map)
> >> return 0;
> >>
> >> + domain = iommu_get_domain_for_dev(dma_dev);
> >> + if ((!domain || domain->type == IOMMU_DOMAIN_IDENTITY) &&
> >> + vhost_vdpa_noiommu && capable(CAP_SYS_RAWIO)) {
> >> + add_taint(TAINT_USER, LOCKDEP_STILL_OK);
> >> + dev_warn(>dev, "Adding kernel taint for noiommu on
> >> device\n");
> >> + v->noiommu_en = true;
> >> + return 0;
> >> + }
> >> bus = dma_dev->bus;
> >> if (!bus)
> >> return -EFAULT;
> >> --
> >> 2.25.1
> >>
> >
> >
>
Re: [PULL 00/20] Net patches
On Wed, Jun 5, 2024 at 6:14 PM Michael Tokarev wrote: > > 04.06.2024 10:37, Jason Wang wrote: > > Akihiko Odaki (18): > >tap: Remove tap_probe_vnet_hdr_len() > >tap: Remove qemu_using_vnet_hdr() > >net: Move virtio-net header length assertion > >net: Remove receive_raw() > >tap: Call tap_receive_iov() from tap_receive() > >tap: Shrink zeroed virtio-net header > >virtio-net: Do not propagate ebpf-rss-fds errors > >virtio-net: Add only one queue pair when realizing > >virtio-net: Copy header only when necessary > >virtio-net: Shrink header byte swapping buffer > >virtio-net: Disable RSS on reset > >virtio-net: Unify the logic to update NIC state for RSS > >virtio-net: Always set populate_hash > >virtio-net: Do not write hashes to peer buffer > >ebpf: Fix RSS error handling > >ebpf: Return 0 when configuration fails > >ebpf: Refactor tun_rss_steering_prog() > >ebpf: Add a separate target for skeleton > > > > Alexey Dobriyan (1): > >virtio-net: drop too short packets early > > > > Andrew Melnychenko (1): > >ebpf: Added traces back. Changed source set for eBPF to 'system'. > > Is there anything in there for qemu-stable? > (NOT picking up without explicit mention of stable) One candidate might be "virtio-net: drop too short packets early". Thanks > > Thanks, > > /mjt > -- > GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. > New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 > ECDF 2C8E > Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 > 8044 65C5 > Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt >
Review Request 75031: [mesos-build] add .git directory to safe directory
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75031/ --- Review request for mesos and Benjamin Mahler. Repository: mesos Description --- [mesos-build] add .git directory to safe directory Diffs - support/mesos-build/entrypoint.sh 865c44aef02d5a8b23a8397e8d3cc5eda331a017 Diff: https://reviews.apache.org/r/75031/diff/1/ Testing --- Thanks, Jason Zhou
[Lldb-commits] [lldb] [lldb] [NFC] Rewrite TestRedefinitionsInInlines.py as an API test (PR #94539)
https://github.com/jasonmolenda closed https://github.com/llvm/llvm-project/pull/94539 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] [NFC] Rewrite TestRedefinitionsInInlines.py as an API test (PR #94539)
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/94539
>From c02e38e5ef017a966ef8b94a56e394309462 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Wed, 5 Jun 2024 15:27:23 -0700
Subject: [PATCH 1/2] [lldb] [NFC] Rewrite TestRedefinitionsInInlines.py as an
API test
Rewrite an inline test as an API test, to be a little easier to
debug, and add some additional checks that we're in the inlined
test1, then step and we are now in the inlined test2 functions.
---
lldb/test/API/lang/c/inlines/Makefile | 3 +
.../c/inlines/TestRedefinitionsInInlines.py | 73 +++
lldb/test/API/lang/c/inlines/main.c | 23 +++---
3 files changed, 74 insertions(+), 25 deletions(-)
create mode 100644 lldb/test/API/lang/c/inlines/Makefile
diff --git a/lldb/test/API/lang/c/inlines/Makefile
b/lldb/test/API/lang/c/inlines/Makefile
new file mode 100644
index 0..f9555f92be8cd
--- /dev/null
+++ b/lldb/test/API/lang/c/inlines/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git a/lldb/test/API/lang/c/inlines/TestRedefinitionsInInlines.py
b/lldb/test/API/lang/c/inlines/TestRedefinitionsInInlines.py
index 024b9dad9b0fb..d48f88ad7d563 100644
--- a/lldb/test/API/lang/c/inlines/TestRedefinitionsInInlines.py
+++ b/lldb/test/API/lang/c/inlines/TestRedefinitionsInInlines.py
@@ -1,14 +1,61 @@
-from lldbsuite.test import lldbinline
-from lldbsuite.test import decorators
-
-lldbinline.MakeInlineTest(
-__file__,
-globals(),
-[
-decorators.expectedFailureAll(
-compiler="clang",
-compiler_version=["<", "3.5"],
-bugnumber="llvm.org/pr27845",
+"""Test that inlined argument variables have their correct location in
debuginfo"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestRedefinitionsInInlines(TestBase):
+
+# https://github.com/llvm/llvm-project/issues/28219
+@skipIf(compiler="clang", compiler_version=["<", "3.5"])
+def test(self):
+self.source = "main.c"
+self.build()
+(target, process, thread, bp1) = lldbutil.run_to_source_breakpoint(
+self, "first breakpoint", lldb.SBFileSpec(self.source, False)
)
-],
-)
+
+bp2 = target.BreakpointCreateBySourceRegex(
+"second breakpoint", lldb.SBFileSpec(self.source, False)
+)
+bp3 = target.BreakpointCreateBySourceRegex(
+"third breakpoint", lldb.SBFileSpec(self.source, False)
+)
+
+# When called from main(), test2 is passed in the value of 42 in 'b'
+self.expect("expression b", DATA_TYPES_DISPLAYED_CORRECTLY,
substrs=["42"])
+
+process.Continue()
+
+self.assertState(process.GetState(), lldb.eStateStopped)
+thread = lldbutil.get_stopped_thread(process,
lldb.eStopReasonBreakpoint)
+self.assertIsNotNone(thread)
+bp_id = thread.GetStopReasonDataAtIndex(0)
+self.assertEqual(bp_id, bp2.GetID())
+
+self.expect("expression b", DATA_TYPES_DISPLAYED_CORRECTLY,
substrs=["42"])
+self.expect("expression c", DATA_TYPES_DISPLAYED_CORRECTLY,
substrs=["84"])
+
+process.Continue()
+
+# Now we're in test1(), and the first thing it does is call test2(24).
"Step in"
+# and check that we have the value 24 as the argument.
+self.assertState(process.GetState(), lldb.eStateStopped)
+thread = lldbutil.get_stopped_thread(process,
lldb.eStopReasonBreakpoint)
+self.assertIsNotNone(thread)
+bp_id = thread.GetStopReasonDataAtIndex(0)
+self.assertEqual(bp_id, bp3.GetID())
+
+frame = thread.GetFrameAtIndex(0)
+self.assertTrue(frame.IsInlined())
+self.assertEqual(frame.GetFunctionName(), "test1")
+
+thread.StepInto()
+
+frame = thread.GetFrameAtIndex(0)
+self.assertTrue(frame.IsInlined())
+self.assertEqual(frame.GetFunctionName(), "test2")
+
+self.expect("expression b", DATA_TYPES_DISPLAYED_CORRECTLY,
substrs=["24"])
diff --git a/lldb/test/API/lang/c/inlines/main.c
b/lldb/test/API/lang/c/inlines/main.c
index 8fe49180800bd..6ecc04dd508fc 100644
--- a/lldb/test/API/lang/c/inlines/main.c
+++ b/lldb/test/API/lang/c/inlines/main.c
@@ -3,23 +3,22 @@
inline void test1(int) __attribute__ ((always_inline));
inline void test2(int) __attribute__ ((always_inline));
+// Called once from main with b==42 then called from test1 with b==24.
void test2(int b) {
-printf("test2(%d)\n", b); //% self.expect("expression b",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["42&quo
[Lldb-commits] [lldb] [lldb] [NFC] Rewrite TestRedefinitionsInInlines.py as an API test (PR #94539)
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/94539
Rewrite an inline test as an API test, to be a little easier to debug, and add
some additional checks that we're in the inlined test1, then step and we are
now in the inlined test2 functions.
>From c02e38e5ef017a966ef8b94a56e394309462 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Wed, 5 Jun 2024 15:27:23 -0700
Subject: [PATCH] [lldb] [NFC] Rewrite TestRedefinitionsInInlines.py as an API
test
Rewrite an inline test as an API test, to be a little easier to
debug, and add some additional checks that we're in the inlined
test1, then step and we are now in the inlined test2 functions.
---
lldb/test/API/lang/c/inlines/Makefile | 3 +
.../c/inlines/TestRedefinitionsInInlines.py | 73 +++
lldb/test/API/lang/c/inlines/main.c | 23 +++---
3 files changed, 74 insertions(+), 25 deletions(-)
create mode 100644 lldb/test/API/lang/c/inlines/Makefile
diff --git a/lldb/test/API/lang/c/inlines/Makefile
b/lldb/test/API/lang/c/inlines/Makefile
new file mode 100644
index 0..f9555f92be8cd
--- /dev/null
+++ b/lldb/test/API/lang/c/inlines/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git a/lldb/test/API/lang/c/inlines/TestRedefinitionsInInlines.py
b/lldb/test/API/lang/c/inlines/TestRedefinitionsInInlines.py
index 024b9dad9b0fb..d48f88ad7d563 100644
--- a/lldb/test/API/lang/c/inlines/TestRedefinitionsInInlines.py
+++ b/lldb/test/API/lang/c/inlines/TestRedefinitionsInInlines.py
@@ -1,14 +1,61 @@
-from lldbsuite.test import lldbinline
-from lldbsuite.test import decorators
-
-lldbinline.MakeInlineTest(
-__file__,
-globals(),
-[
-decorators.expectedFailureAll(
-compiler="clang",
-compiler_version=["<", "3.5"],
-bugnumber="llvm.org/pr27845",
+"""Test that inlined argument variables have their correct location in
debuginfo"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestRedefinitionsInInlines(TestBase):
+
+# https://github.com/llvm/llvm-project/issues/28219
+@skipIf(compiler="clang", compiler_version=["<", "3.5"])
+def test(self):
+self.source = "main.c"
+self.build()
+(target, process, thread, bp1) = lldbutil.run_to_source_breakpoint(
+self, "first breakpoint", lldb.SBFileSpec(self.source, False)
)
-],
-)
+
+bp2 = target.BreakpointCreateBySourceRegex(
+"second breakpoint", lldb.SBFileSpec(self.source, False)
+)
+bp3 = target.BreakpointCreateBySourceRegex(
+"third breakpoint", lldb.SBFileSpec(self.source, False)
+)
+
+# When called from main(), test2 is passed in the value of 42 in 'b'
+self.expect("expression b", DATA_TYPES_DISPLAYED_CORRECTLY,
substrs=["42"])
+
+process.Continue()
+
+self.assertState(process.GetState(), lldb.eStateStopped)
+thread = lldbutil.get_stopped_thread(process,
lldb.eStopReasonBreakpoint)
+self.assertIsNotNone(thread)
+bp_id = thread.GetStopReasonDataAtIndex(0)
+self.assertEqual(bp_id, bp2.GetID())
+
+self.expect("expression b", DATA_TYPES_DISPLAYED_CORRECTLY,
substrs=["42"])
+self.expect("expression c", DATA_TYPES_DISPLAYED_CORRECTLY,
substrs=["84"])
+
+process.Continue()
+
+# Now we're in test1(), and the first thing it does is call test2(24).
"Step in"
+# and check that we have the value 24 as the argument.
+self.assertState(process.GetState(), lldb.eStateStopped)
+thread = lldbutil.get_stopped_thread(process,
lldb.eStopReasonBreakpoint)
+self.assertIsNotNone(thread)
+bp_id = thread.GetStopReasonDataAtIndex(0)
+self.assertEqual(bp_id, bp3.GetID())
+
+frame = thread.GetFrameAtIndex(0)
+self.assertTrue(frame.IsInlined())
+self.assertEqual(frame.GetFunctionName(), "test1")
+
+thread.StepInto()
+
+frame = thread.GetFrameAtIndex(0)
+self.assertTrue(frame.IsInlined())
+self.assertEqual(frame.GetFunctionName(), "test2")
+
+self.expect("expression b", DATA_TYPES_DISPLAYED_CORRECTLY,
substrs=["24"])
diff --git a/lldb/test/API/lang/c/inlines/main.c
b/lldb/test/API/lang/c/inlines/main.c
index 8fe49180800bd..6ecc04dd508fc 100644
--- a/lldb/test/API/lang/c/inlines/main.c
+++ b/lldb/test/API/lang/c/inlines/main.c
@@ -3,23 +3,22 @@
inline void test1(int) __attribute__ ((always_inline));
inline void test2(int) __attribute__ ((always_inline));
+// Called once from main with b==
[Impala-ASF-CR] IMPALA-13119: Fix cost initialization at CostingSegment.java
Jason Fehr has posted comments on this change. ( http://gerrit.cloudera.org:8080/21468 ) Change subject: IMPALA-13119: Fix cost_ initialization at CostingSegment.java .. Patch Set 2: Code-Review+1 LGTM -- To view, visit http://gerrit.cloudera.org:8080/21468 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I5b3c99c87a1d0a08edc8d276cf33d709bd39fe14 Gerrit-Change-Number: 21468 Gerrit-PatchSet: 2 Gerrit-Owner: Riza Suminto Gerrit-Reviewer: Abhishek Rawat Gerrit-Reviewer: David Rorke Gerrit-Reviewer: Impala Public Jenkins Gerrit-Reviewer: Jason Fehr Gerrit-Reviewer: Riza Suminto Gerrit-Reviewer: Wenzhe Zhou Gerrit-Comment-Date: Wed, 05 Jun 2024 21:28:35 + Gerrit-HasComments: No
Re: Ambiguity of "Double-Press Home" has me frustrated
My iPhone doesn’t have a Home button – it’s an iPhone XS. The gesture to reach the list of open apps is to slide up from the bottom of the screen until the second haptic vibration occurs. If this gesture is also available on your phone, you could use it instead of the Home button. From: 'Janina Sajka' via MacVisionaries Date: Wednesday, June 5, 2024 at 12:50To: 'Janina Sajka' via MacVisionaries Subject: Ambiguity of "Double-Press Home" has me frustratedIf I double-press home I usually lad on my list of open apps. There is where I can swipe up with 3 fingers to close, or double tap on an app to return to it. So far so good. The frustration is that sometimes, in circumstances I still can't fully define even after half a year with my iphone as my primary phone, that's not what happens when I double tap on home. Rather I go into Apple Pay with the prompt "Pay with Touch ID. Hold near reader." I thought assigning the same gesture to multiple outcomes was a serious UX design violation. What part of good design am I not understanding. Here's the really annoying bit. Afaik, there's no way to exit out of the "Pay with Touch" screen. I'm stuck until the phone determines to return me to another screen. On Android I would simply invoke the Back gesture (or the Back button), but there ain't no such thing on IOS! Colour me purple angry. Janina 'Janina Sajka' via MacVisionaries writes: > I am stuck this way as well. And my resolution suggests I wait to see > what's announced this fall. > > Janina > > 'E.T.' via MacVisionaries writes: > > Thanks, that helped as I did not hear that correctly. Now I also need a > > new iPhone as my 8+ is not supported. Soon I hope to get both. > > > > From E.T.'s Keyboard... > > "Alone we can do so little; together we can do so much." > > -Helen Keller > > My e-Mail: > > ancient.ali...@icloud.com > > > > On 6/4/2024 9:30 AM, Steve Matzura wrote: > > > S/M = small to medium, typically 130-180mm; M/L mean medium to large, > > > typically 150-200mm. 1 inch equals 25mm, so if you have an eight-inch > > > wrist, you'll want the M/L band. > > > > > > > > > On 6/4/2024 12:12 PM, 'E.T.' via MacVisionaries wrote: > > > > Going through the choices on the Apple store app, some of them say > > > > ,"s/l" "m/l". What do they mean? Again, thanks. > > > > > > > > From E.T.'s Keyboard... > > > > "Alone we can do so little; together we can do so much." > > > > -Helen Keller > > > > My e-Mail: > > > > ancient.ali...@icloud.com > > > > > > > > On 6/4/2024 6:58 AM, 'Donna Goodin' via MacVisionaries wrote: > > > > > ET, > > > > > > > > > > This really is a question of personal taste. Personally,I find > > > > > the default band a little too casual. I wanted something I > > > > > would be comfortable wearing when dressed up. So I have the > > > > > Milanese band???at least I think that???s what it???s called. > > > > > It???s a metal band with clasp, and I like it much better than > > > > > any of the bands that come with the watch. > > > > > > > > > > Another thing to remember is that you are not limited to > > > > > Apple???s band selection. You can also buy a band from Amazon. > > > > > That???s what my husband did, and he???s been very happy with > > > > > his. > > > > > Best, > > > > > Donna > > > > > > > > > > > > > > > > On Jun 4, 2024, at 3:40 PM, 'E.T.' via MacVisionaries > > > > > > wrote: > > > > > > > > > > > > Steve and Donna, > > > > > > Appreciate this. I am quite willing to save myself $100. > > > > > > My iPhone is always with me. > > > > > > > > > > > > What about the watch band? If I was in walking distance > > > > > > of an Apple store, I could go there and look.Other than > > > > > > colors, is the default band decent? Thanks. > > > > > > > > > > > > From E.T.'s Keyboard... > > > > > > "Alone we can do so little; together we can do so much." > > > > > > -Helen Keller > > > > > > My e-Mail: > > > > > > ancient.ali...@icloud.com > > > > > > > > > > > > On 6/3/2024 9:54 PM, 'Donna Goodin' via MacVisionaries wrote: > > > > > > > Hi ET, > > > > > > > I agree with everything that others have said. The one > > > > > > > thing I would add is that personally, I don???t really > > > > > > > like taking phone calls on my watch. This is, of > > > > > > > course, subjective, but I mention it because if I > > > > > > > remember correctly, you have hearing loss, and the > > > > > > > reason I don???t like using the watch for phone calls, > > > > > > > is that the sound isn???t very good. It might be > > > > > > > something that wouldn???t be useful for you, and that > > > > > > > that case, the option of using your watch without your > > > > > > > phone would be less wortwhile. I don???t carry my phone > > > > > > > with me all the time. When I???m at home I set it down > > > > > > > and leave it in one place, and it still syncs with the > > > > > > > watch. As you can probably tell, personally, I don???t > > > > > > > think the cellular version is worth the extra money. > > > > > > >
Re: Purpose of IndexUpgraderTool
Awesome - always refreshing to hear everyone leaning the same direction! And thanks Uwe for the additional context! I'll push up a PR to take this out of the ref-guide shortly. On Tue, Jun 4, 2024 at 7:07 AM Uwe Schindler wrote: > > Hi, > > I think we should remove the page from the refguide. > > I won't remove that tool from Lucene's JARs as it is a good example vor the > > Actually there are many othe rthings some customers of myself wanted to > upgrade. I you have one, lead them to me. I helped a customer which was > unable to reindex and stuck on 3.x to go from Lucene 3 to Lucene 6 with > also converting all NumericFields to PointFields and adding docValues in > the process too. But this is not as easy as a simple IndexUpgrader tool. > If it would not be so hard to setup (you need several versions installed > in parallel), I would open it up on github. > > The tool does the following: > > * adds DocValues for all fields using the Uninverter (still available > in Lucene 6.x). It basically does the same like Solr, it just uses > addIndexes(CodecReader) with a Custom CodecReader and patch of > FieldInfos. > * converts NumericField to PointField. Same here, it just uses > addIndexes(CodecReader), but the CodecReader patches Fieldinfos and > lucily it is able to use the termsenum of the legacy numeric field > to extract the numeric values and then during merging it feeds the > numeric values (which are luckily also sorted correctly) to the > BKDWriter. The BKDWriter then does the rest and expands the tree > automatically :-) > > So basically some people want to convert old indexes, but the plain > IndexUpgrader is of little use. The only thing it does is to upgrade all > segments with older versions to actual codec version. This would happen > during normal use, too. The main reason why it existed was for the > migration 3 -> 4 where the terms enum has to change the order during > iteration (UTF-16 of Lucene 3 has a different order than UTF-8 starting > with Lucene 4). This slowed down searches, so people wanted to merge all > their segments to newest version. > > Uwe > > Am 04.06.2024 um 01:13 schrieb Jan Høydahl: > > I used it back in the days when you could migrate from v3->4->5->6. It > > solved > > the issue that Solr 6 could only read a Lucene 6 or Lucene 5 index, but > > after the > > sequence of upgrades you'd get there. I even wrote a wrapper to automate it > > all at > > https://github.com/cominvent/solr-tools/tree/master/upgradeindex > > > > However, now that Lucene 9 refuses to work with any index created before > > Lucene 8, > > I agree with Jason that I cannot see any utility for the upgrade tool > > anymore. Since, > > if you have a Solr 6 index, it won't work in Solr 9 even if you used the > > upgrader. > > And if you already have a Lucene 8 index, no need to upgrade by hand, just > > start > > Solr 9 on top of the Lucene 8 index and it will be upgraded. > > > > +1 to remove mention from ref-guide. > > > > PS: If the upgrader tool was able to patch the original-index-version from > > the binary > > index (and user understands the risks), then there could be some utility. > > But I'm not > > aware of such an option. > > > > Jan > > > >> 3. juni 2024 kl. 21:20 skrev Gus Heck: > >> > >> I've fielded many questions on this from clients. Folks who have managed > >> databases expect to be able to upgrade the data serially across versions > >> and such, so these questions come up alot with organizations early in their > >> journey with search. Essentially, I tell them that it's a stop gap tool for > >> use if there's a serious security issue and you really need to move up one > >> version to get away from the security issue, but otherwise the correct > >> procedure is to re-index. (And this is sometimes when I find out if they've > >> really planned for reindexing or not). A down-side of the existence of this > >> tool is that its presence in the ref guide allows people to prolong the > >> period where they confuse managing a search index with managing a database. > >> That said, I think it may have a place to help folks who got going without > >> knowing enough about search engines to extend the period they have to dig > >> themselves out of bad situations (by allowing an upgrade while they figure > >> out how they are going to handle re-indexing more data than they previously > >> planned on indexing all at once). So far every one of my clients has taken > >> my advice an
Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
> Jiri Konecny writes: > Also a question, is kickstart command for RDP requirement for you? Or > is inst.rdp (replacement of inst.vnc) enough to work with? We are > trying to find out if we can drop the kickstart command. I don't particularly care about how the functionality gets activated; in my case it's not something that would need to come in though the kickstart file. However, I could see situations where it would be useful to have that specified in the kickstart file, such as a hypothetical deployment system. It might, for example, want to direct anaconda to send the display to an appropriate place that could be proxied or recorded. That location might be complicated or variable and not necessarily something that could be baked into the boot media or typed in at boot time. - J< -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Review Request 75030: [mesos-readme] clarify mesos-build instructions for uploading to dockerhub
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75030/ --- Review request for mesos and Benjamin Mahler. Repository: mesos Description --- [mesos-readme] clarify mesos-build instructions for uploading to dockerhub Diffs - support/mesos-build/README.md PRE-CREATION Diff: https://reviews.apache.org/r/75030/diff/1/ Testing --- Thanks, Jason Zhou
Re: Review Request 75027: [mesos-build] update review tidybot & docker-build.sh to support ubuntu 20.04
> On June 5, 2024, 4:41 a.m., Benjamin Mahler wrote: > > support/mesos-build/entrypoint.sh > > Lines 26 (patched) > > <https://reviews.apache.org/r/75027/diff/2/?file=2288518#file2288518line26> > > > > Probably helps to document what this is for? I will land it as is > > without it but please follow up with a patch that adds a comment :) https://reviews.apache.org/r/75029/ Documented along with a small change here - Jason --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75027/#review226508 --- On June 4, 2024, 3:22 p.m., Jason Zhou wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/75027/ > --- > > (Updated June 4, 2024, 3:22 p.m.) > > > Review request for mesos and Benjamin Mahler. > > > Repository: mesos > > > Description > --- > > The reviewbot, tidybot, and our docker-build scripts > have been updated to use or accomodate for ubuntu 20.04. > > > Diffs > - > > support/docker-build.sh 4f4019001755082c8dcbea5cb0043363940d383c > support/jenkins/reviewbot.sh 349e18dfdb3786edf34300b88e7b03014ab1af59 > support/mesos-build/entrypoint.sh 865c44aef02d5a8b23a8397e8d3cc5eda331a017 > support/mesos-tidy/Dockerfile db66a8575ba0b518ce550bf1c7cfb3d898dc9f42 > > > Diff: https://reviews.apache.org/r/75027/diff/2/ > > > Testing > --- > > > Thanks, > > Jason Zhou > >
Review Request 75029: [mesos-build] add correct directory to git safe directory & add explanation
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75029/ --- Review request for mesos and Benjamin Mahler. Repository: mesos Description --- Previously, the entrypoint.sh added /SRC/.git as a safe directory after the git clone, which was not useful. We now add it /SRC/ as a safe directory before the git clone. In addition, a note has been added to explain why we are adding SRC to the safe directory. Diffs - support/mesos-build/entrypoint.sh 865c44aef02d5a8b23a8397e8d3cc5eda331a017 Diff: https://reviews.apache.org/r/75029/diff/1/ Testing --- Thanks, Jason Zhou
Re: [RE-wrenches] Sol-Ark 15k solar panel frame grounding
This is a partial backup scenario and the main service panel has a solid neutral to ground bond. I have not been able to find anywhere else where there is a bond, but there is always the chance that there is a neutral wire in a switch box or outlet box somewhere in the house that is touching an equipment ground or metallic enclosure. On Wed, Jun 5, 2024, 9:53 AM Mac Lewis wrote: > Hi Jason, > > You should be able to land your PV EGC in the inverter ground bar. You > could do a quick resistance check to verify the +, - PV > > Is there a bond somewhere (upstream service panel or in the Sol-Ark > itself) between ground and neutral? If not, this can cause this fault. > > On Wed, Jun 5, 2024 at 7:03 AM Jason Szumlanski via RE-wrenches < > re-wrenches@lists.re-wrenches.org> wrote: > >> Can anybody clarify the following instruction from the manual? >> >> "GND the panel MOUNTS/FRAMES to any GND outside the circuit via 12AWG >> wire" >> >> Does this mean do not connect the array equipment grounding conductor to >> the grounding terminal in the inverter? Where would be the suggested place >> to connect the equipment grounding conductor, and why does it make a >> difference? It would still be electrically bonded to the grounding terminal >> in the inverter. >> >> I'm asking because I do, in fact, have an equipment grounding conductor >> from the array connected to the ground terminal in the inverter at a home. >> I am getting an F08 GFDI fault. The manual doesn't say anything about the >> DC side with respect to this error. It suggests it is an AC current leakage >> to ground. But Sol-Ark tech support suggested that I disconnect the PV to >> rule it out as a source of the fault. >> >> >> >> Jason Szumlanski >> Florida Solar Design Group >> ___ >> List sponsored by Redwood Alliance >> >> Pay optional member dues here: http://re-wrenches.org >> >> List Address: RE-wrenches@lists.re-wrenches.org >> >> Change listserver email address & settings: >> http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.org >> >> There are two list archives for searching. When one doesn't work, try the >> other: >> https://www.mail-archive.com/re-wrenches@lists.re-wrenches.org/ >> http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org >> >> List rules & etiquette: >> http://www.re-wrenches.org/etiquette.htm >> >> Check out or update participant bios: >> http://www.members.re-wrenches.org >> >> > > -- > > > > Mac Lewis > > *"Yo solo sé que no sé nada." -Sócrates* > ___ List sponsored by Redwood Alliance Pay optional member dues here: http://re-wrenches.org List Address: RE-wrenches@lists.re-wrenches.org Change listserver email address & settings: http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.org There are two list archives for searching. When one doesn't work, try the other: https://www.mail-archive.com/re-wrenches@lists.re-wrenches.org/ http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org List rules & etiquette: http://www.re-wrenches.org/etiquette.htm Check out or update participant bios: http://www.members.re-wrenches.org
[RE-wrenches] Sol-Ark 15k solar panel frame grounding
Can anybody clarify the following instruction from the manual? "GND the panel MOUNTS/FRAMES to any GND outside the circuit via 12AWG wire" Does this mean do not connect the array equipment grounding conductor to the grounding terminal in the inverter? Where would be the suggested place to connect the equipment grounding conductor, and why does it make a difference? It would still be electrically bonded to the grounding terminal in the inverter. I'm asking because I do, in fact, have an equipment grounding conductor from the array connected to the ground terminal in the inverter at a home. I am getting an F08 GFDI fault. The manual doesn't say anything about the DC side with respect to this error. It suggests it is an AC current leakage to ground. But Sol-Ark tech support suggested that I disconnect the PV to rule it out as a source of the fault. Jason Szumlanski Florida Solar Design Group ___ List sponsored by Redwood Alliance Pay optional member dues here: http://re-wrenches.org List Address: RE-wrenches@lists.re-wrenches.org Change listserver email address & settings: http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.org There are two list archives for searching. When one doesn't work, try the other: https://www.mail-archive.com/re-wrenches@lists.re-wrenches.org/ http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org List rules & etiquette: http://www.re-wrenches.org/etiquette.htm Check out or update participant bios: http://www.members.re-wrenches.org
Re: [PATCH v2 02/22] iommufd: Use iommu_user_domain_alloc()
On Wed, Jun 05, 2024 at 10:17:07AM +0800, Baolu Lu wrote:
> On 6/5/24 12:51 AM, Jason Gunthorpe wrote:
> > On Tue, Jun 04, 2024 at 09:51:14AM +0800, Lu Baolu wrote:
> > > Replace iommu_domain_alloc() with iommu_user_domain_alloc().
> > >
> > > Signed-off-by: Lu Baolu
> > > ---
> > > drivers/iommu/iommufd/hw_pagetable.c | 20 +---
> > > 1 file changed, 5 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/iommu/iommufd/hw_pagetable.c
> > > b/drivers/iommu/iommufd/hw_pagetable.c
> > > index 33d142f8057d..ada05fccb36a 100644
> > > --- a/drivers/iommu/iommufd/hw_pagetable.c
> > > +++ b/drivers/iommu/iommufd/hw_pagetable.c
> > > @@ -127,21 +127,11 @@ iommufd_hwpt_paging_alloc(struct iommufd_ctx *ictx,
> > > struct iommufd_ioas *ioas,
> > > hwpt_paging->ioas = ioas;
> > > hwpt_paging->nest_parent = flags & IOMMU_HWPT_ALLOC_NEST_PARENT;
> > > - if (ops->domain_alloc_user) {
> > > - hwpt->domain = ops->domain_alloc_user(idev->dev, flags, NULL,
> > > - user_data);
> >
> >
> > > - if (IS_ERR(hwpt->domain)) {
> > > - rc = PTR_ERR(hwpt->domain);
> > > - hwpt->domain = NULL;
> > > - goto out_abort;
> > > - }
> > > - hwpt->domain->owner = ops;
> > > - } else {
> > > - hwpt->domain = iommu_domain_alloc(idev->dev->bus);
> > > - if (!hwpt->domain) {
> > > - rc = -ENOMEM;
> > > - goto out_abort;
> > > - }
> > > + hwpt->domain = iommu_user_domain_alloc(idev->dev, flags);
> > > + if (IS_ERR(hwpt->domain)) {
> >
> > Where did the user_data go???
>
> The user_data is not used in allocating a paging user domain, so I
> skipped it.
That's not true.. We have no driver using it right now, but it is
definately part of the uAPI and a driver could start using it. That is
why it was hooked up in the first place.
> In my first try, I simply replaced iommu_domain_alloc() with a new
> paging domain allocation interface. On second thought, it occurred to me
> why not use separate interfaces for different purposes? Even though from
> an iommu perspective, they both use paging domains.
If we want to do that then it needs to forward all the args
> The @flags and @user_data are defined in uapi/linux/iommufd.h, which is
> specific to iommufd. Wrapping them in a common interface for broader use
> seems awkward.
Right, you'd have to forward declare the struct and just let it
be. Really nothing but iommufd could call this API.
> So, perhaps we could return to my original idea? Let's just expose one
> interface, iommu_paging_domain_alloc(), and replace iommu_domain_alloc()
> with it everywhere?
That's OK too, this above doesn't really need to be changed, some of
the concept here was that iommufd-only ops would just be directly
called by iommufd itself, to discourage future abuse.
Jason
Re: [PATCH RFC 4/8] target/riscv: Support generic CSR indirect access
The predicate functions should contain the access control by the
state-enable CSRs, which is not presented in this patch. Do you mind
that I take over the indirect CSR access control part? The Signed-off-by
will be kept.
Atish Patra 於 2024/2/17 上午 08:01 寫道:
From: Kaiwen Xue
This adds the indirect access registers required by sscsrind/smcsrind
and the operations on them. Note that xiselect and xireg are used for
both AIA and sxcsrind, and the behavior of accessing them depends on
whether each extension is enabled and the value stored in xiselect.
Co-developed-by: Atish Patra
Signed-off-by: Atish Patra
Signed-off-by: Kaiwen Xue
---
target/riscv/cpu_bits.h | 28 +++-
target/riscv/csr.c | 146 +++-
2 files changed, 169 insertions(+), 5 deletions(-)
diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index 0ee91e502e8f..3a66f83009b5 100644
--- a/target/riscv/cpu_bits.h
+++ b/target/riscv/cpu_bits.h
@@ -176,6 +176,13 @@
#define CSR_MISELECT0x350
#define CSR_MIREG 0x351
+/* Machine Indirect Register Alias */
+#define CSR_MIREG2 0x352
+#define CSR_MIREG3 0x353
+#define CSR_MIREG4 0x355
+#define CSR_MIREG5 0x356
+#define CSR_MIREG6 0x357
+
/* Machine-Level Interrupts (AIA) */
#define CSR_MTOPEI 0x35c
#define CSR_MTOPI 0xfb0
@@ -225,6 +232,13 @@
#define CSR_SISELECT0x150
#define CSR_SIREG 0x151
+/* Supervisor Indirect Register Alias */
+#define CSR_SIREG2 0x152
+#define CSR_SIREG3 0x153
+#define CSR_SIREG4 0x155
+#define CSR_SIREG5 0x156
+#define CSR_SIREG6 0x157
+
/* Supervisor-Level Interrupts (AIA) */
#define CSR_STOPEI 0x15c
#define CSR_STOPI 0xdb0
@@ -291,6 +305,13 @@
#define CSR_VSISELECT 0x250
#define CSR_VSIREG 0x251
+/* Virtual Supervisor Indirect Alias */
+#define CSR_VSIREG2 0x252
+#define CSR_VSIREG3 0x253
+#define CSR_VSIREG4 0x255
+#define CSR_VSIREG5 0x256
+#define CSR_VSIREG6 0x257
+
/* VS-Level Interrupts (H-extension with AIA) */
#define CSR_VSTOPEI 0x25c
#define CSR_VSTOPI 0xeb0
@@ -847,10 +868,13 @@ typedef enum RISCVException {
#define ISELECT_IMSIC_EIE630xff
#define ISELECT_IMSIC_FIRSTISELECT_IMSIC_EIDELIVERY
#define ISELECT_IMSIC_LAST ISELECT_IMSIC_EIE63
-#define ISELECT_MASK 0x1ff
+#define ISELECT_MASK_AIA 0x1ff
+
+/* MISELECT, SISELECT, and VSISELECT bits (AIA) */
+#define ISELECT_MASK_SXCSRIND 0xfff
Could you rename ISELECT_MASK_SXCSRIND to ISELECT_MASK_CSRIND to keep
the naming consistency with ISELECT_MASK_AIA?
/* Dummy [M|S|VS]ISELECT value for emulating [M|S|VS]TOPEI CSRs */
-#define ISELECT_IMSIC_TOPEI(ISELECT_MASK + 1)
+#define ISELECT_IMSIC_TOPEI(ISELECT_MASK_AIA + 1)
/* IMSIC bits (AIA) */
#define IMSIC_TOPEI_IID_SHIFT 16
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 89a1325a02a5..a1c10f1d010a 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -287,6 +287,17 @@ static int aia_any32(CPURISCVState *env, int csrno)
return any32(env, csrno);
}
+static RISCVException sxcsrind_any(CPURISCVState *env, int csrno)
Could you rename sxcsrind_any() to csrind_any() to keep naming
consistency with aia_any()?
+{
+RISCVCPU *cpu = env_archcpu(env);
+
+if (!cpu->cfg.ext_smcsrind) {
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+return RISCV_EXCP_NONE;
+}
+
static int sxcsrind_or_aia_any(CPURISCVState *env, int csrno)
{
if (!riscv_cpu_cfg(env)->ext_smaia && !riscv_cpu_cfg(env)->ext_smcsrind) {
@@ -355,6 +366,17 @@ static int aia_smode32(CPURISCVState *env, int csrno)
return smode32(env, csrno);
}
+static RISCVException sxcsrind_smode(CPURISCVState *env, int csrno)
Could you rename sxcsrind_smode() to csrind_smode() to keep naming
consistency with aia_smode()?
+{
+RISCVCPU *cpu = env_archcpu(env);
+
+if (!cpu->cfg.ext_sscsrind) {
S-mode CSRs are defined in Smcsrind as well. If both Smcsrind and
Sscsrind are disabled, return RISCV_EXCP_ILLEGAL_INST.
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
A virtual instruction exception should be raised here for attempts from
VU-mode to access siselect or sireg*.
+return smode(env, csrno);
+}
+
static int sxcsrind_or_aia_smode(CPURISCVState *env, int csrno)
{
if (!riscv_cpu_cfg(env)->ext_ssaia && !riscv_cpu_cfg(env)->ext_sscsrind) {
@@ -383,6 +405,17 @@ static RISCVException hmode32(CPURISCVState *env, int
csrno)
}
+static RISCVException sxcsrind_hmode(CPURISCVState *env, int csrno)
Could you rename sxcsrind_hmode() to csrind_hmode() to keep naming
consistency with aia_hmode()?
+{
+RISCVCPU *cpu = env_archcpu(env);
+
+if
Re: [PATCH RFC 2/8] target/riscv: Decouple AIA processing from xiselect and xireg
Atish Patra 於 2024/2/17 上午 08:01 寫道:
From: Kaiwen Xue
Since xiselect and xireg also will be of use in sxcsrind, AIA should
have its own separated interface when those CSRs are accessed.
Signed-off-by: Atish Patra
Signed-off-by: Kaiwen Xue
---
target/riscv/csr.c | 147 +
1 file changed, 122 insertions(+), 25 deletions(-)
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 8829dee7bc75..1af0c8890a2b 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -287,6 +287,15 @@ static int aia_any32(CPURISCVState *env, int csrno)
return any32(env, csrno);
}
+static int sxcsrind_or_aia_any(CPURISCVState *env, int csrno)
Could you rename the function as csrind_or_aia_any() to keep the naming
consistency with aia?
+{
+if (!riscv_cpu_cfg(env)->ext_smaia && !riscv_cpu_cfg(env)->ext_smcsrind) {
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+return any(env, csrno);
+}
+
static RISCVException smode(CPURISCVState *env, int csrno)
{
if (riscv_has_ext(env, RVS)) {
@@ -323,6 +332,15 @@ static int aia_smode32(CPURISCVState *env, int csrno)
return smode32(env, csrno);
}
+static int sxcsrind_or_aia_smode(CPURISCVState *env, int csrno)
Could you rename the function as csrind_or_aia_smode() to keep the
naming consistency with aia?
+{
+if (!riscv_cpu_cfg(env)->ext_ssaia && !riscv_cpu_cfg(env)->ext_sscsrind) {
S-mode CSRs are defined in Smaia and Smcsrind as well. We should ensure
at least one of Smaia, Ssaia, Smcsrind, Sscsrind is enabled.
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+return smode(env, csrno);
+}
+
static RISCVException hmode(CPURISCVState *env, int csrno)
{
if (riscv_has_ext(env, RVH)) {
@@ -342,6 +360,15 @@ static RISCVException hmode32(CPURISCVState *env, int
csrno)
}
+static int sxcsrind_or_aia_hmode(CPURISCVState *env, int csrno)
Could you rename the function as csrind_or_aia_hmode() to keep the
naming consistency with aia?
+{
+if (!riscv_cpu_cfg(env)->ext_ssaia && !riscv_cpu_cfg(env)->ext_sscsrind) {
Hypervisor and VS CSRs are defined in Smaia and Smcsrind as well. We
should ensure at least one of Smaia, Ssaia, Smcsrind, Sscsrind is enabled.
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+return hmode(env, csrno);
+}
+
static RISCVException umode(CPURISCVState *env, int csrno)
{
if (riscv_has_ext(env, RVU)) {
@@ -1804,13 +1831,29 @@ static int aia_xlate_vs_csrno(CPURISCVState *env, int
csrno)
};
}
+static int sxcsrind_xlate_vs_csrno(CPURISCVState *env, int csrno)
Could you rename the function as csrind_xlate_vs_csrno() to keep the
naming consistency with aia_xlate_vs_csrno()?
+{
+if (!env->virt_enabled) {
+return csrno;
+}
+
+switch (csrno) {
+case CSR_SISELECT:
+return CSR_VSISELECT;
+case CSR_SIREG:
+return CSR_VSIREG;
+default:
+return csrno;
+};
+}
+
static int rmw_xiselect(CPURISCVState *env, int csrno, target_ulong *val,
target_ulong new_val, target_ulong wr_mask)
{
target_ulong *iselect;
/* Translate CSR number for VS-mode */
-csrno = aia_xlate_vs_csrno(env, csrno);
+csrno = sxcsrind_xlate_vs_csrno(env, csrno);
/* Find the iselect CSR based on CSR number */
switch (csrno) {
@@ -1839,6 +1882,12 @@ static int rmw_xiselect(CPURISCVState *env, int csrno,
target_ulong *val,
return RISCV_EXCP_NONE;
}
+static bool xiselect_aia_range(target_ulong isel)
+{
+return (ISELECT_IPRIO0 <= isel && isel <= ISELECT_IPRIO15) ||
+ (ISELECT_IMSIC_FIRST <= isel && isel <= ISELECT_IMSIC_LAST);
+}
+
static int rmw_iprio(target_ulong xlen,
target_ulong iselect, uint8_t *iprio,
target_ulong *val, target_ulong new_val,
@@ -1884,44 +1933,44 @@ static int rmw_iprio(target_ulong xlen,
return 0;
}
-static int rmw_xireg(CPURISCVState *env, int csrno, target_ulong *val,
- target_ulong new_val, target_ulong wr_mask)
+static int rmw_xireg_aia(CPURISCVState *env, int csrno,
+ target_ulong isel, target_ulong *val,
+ target_ulong new_val, target_ulong wr_mask)
{
-bool virt, isel_reserved;
-uint8_t *iprio;
+bool virt = false, isel_reserved = false;
int ret = -EINVAL;
-target_ulong priv, isel, vgein;
-
-/* Translate CSR number for VS-mode */
-csrno = aia_xlate_vs_csrno(env, csrno);
+uint8_t *iprio;
+target_ulong priv, vgein;
-/* Decode register details from CSR number */
-virt = false;
-isel_reserved = false;
+/* VS-mode CSR number passed in has already been translated */
switch (csrno) {
case CSR_MIREG:
+if (!riscv_cpu_cfg(env)->ext_smaia) {
+goto done;
+}
iprio = env->miprio;
-isel = env->miselect;
priv = PRV_M;
break;
case
Re: [PATCH 5/6] target/riscv: Add CTR sctrclr instruction.
Chapter 5 describes the CTR behavior when Smstaten is enabled, but it does not talk about the CTR behavior when Smstateen is disabled, that is, there is no mstateen0 and hstateen0 CSR. The spec states: * Attempts to access sctrdepth from VS-mode or VU-mode raise a virtual-instruction exception, unless CTR state enable access restrictions apply. * sctrdepth is not included in the above list of supervisor CTR state controlled by hstateen0.CTR since accesses to sctrdepth from VS-mode raise a virtual-instruction exception regardless of the value of hstateen0.CTR. Below is my understanding: * If Smstateen is enabled: o If mstateen0.CTR=0: + Attempts to access sctrctl, vsctrctl, sctrdepth, or sctrstatus raise an illegal-instruction exception for privilege modes less privileged than M-mode. + Attempts to access sireg* when siselect is in 0x200..0x2FF, or vsireg* when vsiselect is in 0x200..0x2FF raise an illegal-instruction exception for privilege modes less privileged than M-mode. + Execution of the SCTRCLR instruction raises an illegal-instruction exception for privilege modes less privileged than M-mode. o If mstateen.CTR=1: + Attempts to access sctrctl, vsctrctl, sctrdepth, or sctrstatus raise an illegal-instruction exception for U-mode. + Attempts to access sireg* when siselect is in 0x200..0x2FF, or vsireg* when vsiselect is in 0x200..0x2FF raise an illegal-instruction exception for U-mode. + Execution of the SCTRCLR instruction raises an illegal-instruction exception for U-mode. + If H extension is enabled: # If hstateen0.CTR = 0: * Attempts to access sctrctl, vsctrctl, sctrdepth, or sctrstatus raise an virtual-instruction exception for VU-mode and VS-mode. * Attempts to access sireg* when siselect is in 0x200..0x2FF, or vsireg* when vsiselect is in 0x200..0x2FF raise an virtual-instruction exception for VU-mode and VS-mode. * Execution of the SCTRCLR instruction raises an virtual-instruction exception for VU-mode and VS-mode. # If hstateen0.CTR = 1: * Attempts to access sctrctl, vsctrctl, sctrdepth, or sctrstatus raise an virtual-instruction exception for VU-mode. * *_/Attempts to access sctrdepth raise an virtual-instruction exception for "VS-mode"/._* * Attempts to access sireg* when siselect is in 0x200..0x2FF, or vsireg* when vsiselect is in 0x200..0x2FF raise an virtual-instruction exception for VU-mode. * Execution of the SCTRCLR instruction raises an virtual-instruction exception for VU-mode. * If Smstateen is disabled: o Attempts to access sctrctl, vsctrctl, sctrdepth, or sctrstatus raise an illegal-instruction exception for U-mode. o Attempts to access sireg* when siselect is in 0x200..0x2FF, or vsireg* when vsiselect is in 0x200..0x2FF raise an illegal-instruction exception for U-mode. o Execution of the SCTRCLR instruction raises an illegal-instruction exception for U-mode. o If H extension is enabled: + Attempts to access sctrctl, vsctrctl, sctrdepth, or sctrstatus raise an virtual-instruction exception for VU-mode. + */_Attempts to access sctrdepth raise an virtual-instruction exception for "VS-mode"._/* + Attempts to access sireg* when siselect is in 0x200..0x2FF, or vsireg* when vsiselect is in 0x200..0x2FF raise an virtual-instruction exception for VU-mode. + Execution of the SCTRCLR instruction raises an virtual-instruction exception for VU-mode. If there is any misunderstanding, please let me know. Also Sstateen0 does not involve in CTR. Am I correct? Thanks in advance. Beeman Strong 於 2024/6/5 上午 02:46 寫道: On Tue, Jun 4, 2024 at 10:19 AM Jason Chien wrote: Rajnesh Kanwal 於 2024/5/30 上午 12:09 寫道: > CTR extension adds a new instruction sctrclr to quickly > clear the recorded entries buffer. > > Signed-off-by: Rajnesh Kanwal > --- > target/riscv/cpu.h | 1 + > target/riscv/cpu_helper.c | 7 +++ > target/riscv/insn32.decode | 1 + > target/riscv/insn_trans/trans_privileged.c.inc | 10 ++ > target/riscv/op_helper.c | 5 + > 5 files changed, 24 insertions(+) > > diff --git a/target/riscv/cpu.h b/t
Re: www/qt5-webengine fails to compile
_xfa_tiff=false > qtwebengine_target="/usr/ports/www/qt5-webengine/work/.build/src/pdf/release:QtPdf" > > > >^ > The variable "use_bundled_fontconfig" was set as a build argument > but never appeared in a declare_args() block in any buildfile. > > To view all possible args, run "gn args --list " > > The build continued as if that argument was unspecified. > > Done. Made 14473 targets from 2283 files in 3328ms > *** [sub-gn_run-pro-make_first] Error code 6 > > make[2]: stopped in /usr/ports/www/qt5-webengine/work/.build/src/pdf > 1 error > > make[2]: stopped in /usr/ports/www/qt5-webengine/work/.build/src/pdf > *** [sub-pdf-make_first] Error code 2 > > make[1]: stopped in /usr/ports/www/qt5-webengine/work/.build/src > 4 errors > > make[1]: stopped in /usr/ports/www/qt5-webengine/work/.build/src > *** [sub-src-make_first] Error code 2 > > make: stopped in /usr/ports/www/qt5-webengine/work/.build > 1 error > > make: stopped in /usr/ports/www/qt5-webengine/work/.build > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/www/qt5-webengine > *** Error code 1 > > Stop. > make: stopped in /usr/ports/www/qt5-webengine > > ===>>> make build failed for www/qt5-webengine > ===>>> Aborting update > > > ===>>> You can restart from the point of failure with this command line: >portmaster www/qt5-webengine > > This command has been saved to ~/portmasterfail.txt > > > -- > William Bulley > E-MAIL: w...@umich.edu > This looks like bugs 278279 [1] and 278633 [2] again. You will have to deinstall the currently installed version of www/qt5-webengine before attempting to rebuild. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278279 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278633 - Jason
Re: [PATCH 0/6] target/riscv: Add support for Control Transfer Records Ext.
Thank you for pointing that out. CTR does not use miselect and mireg*. There is no dependency on Smcsrind. I believe the spec needs to be corrected. Chapter 1 states that: Smctr depends on the Smcsrind extension, while Ssctr depends on the Sscsrind extension. Further, both Smctr and Ssctr depend upon implementation of S-mode. Beeman Strong 於 2024/6/5 上午 06:32 寫道: There is no dependency on Smcsrind, only Sscsrind. On Tue, Jun 4, 2024 at 12:29 AM Jason Chien wrote: Smctr depends on the Smcsrind extension, Ssctr depends on the Sscsrind extension, and both Smctr and Ssctr depend upon implementation of S-mode. There should be a dependency check in riscv_cpu_validate_set_extensions(). Rajnesh Kanwal 於 2024/5/30 上午 12:09 寫道: > This series enables Control Transfer Records extension support on riscv > platform. This extension is similar to Arch LBR in x86 and BRBE in ARM. > The Extension has been stable and the latest release can be found here [0] > > CTR extension depends on couple of other extensions: > > 1. S[m|s]csrind : The indirect CSR extension [1] which defines additional > ([M|S|VS]IREG2-[M|S|VS]IREG6) register to address size limitation of > RISC-V CSR address space. CTR access ctrsource, ctrtartget and ctrdata > CSRs using sscsrind extension. > > 2. Smstateen: The mstateen bit[54] controls the access to the CTR ext to > S-mode. > > 3. Sscofpmf: Counter overflow and privilege mode filtering. [2] > > The series is based on Smcdeleg/Ssccfg counter delegation extension [3] > patches. CTR itself doesn't depend on counter delegation support. This > rebase is basically to include the Smcsrind patches. > > Due to the dependency of these extensions, the following extensions must be > enabled to use the control transfer records feature. > > "smstateen=true,sscofpmf=true,smcsrind=true,sscsrind=true,smctr=true,ssctr=true" > > Here is the link to a quick guide [5] to setup and run a basic perf demo on > Linux to use CTR Ext. > > The Qemu patches can be found here: > https://github.com/rajnesh-kanwal/qemu/tree/ctr_upstream > > The opensbi patch can be found here: > https://github.com/rajnesh-kanwal/opensbi/tree/ctr_upstream > > The Linux kernel patches can be found here: > https://github.com/rajnesh-kanwal/linux/tree/ctr_upstream > > [0]:https://github.com/riscv/riscv-control-transfer-records/release > [1]:https://github.com/riscv/riscv-indirect-csr-access > [2]:https://github.com/riscvarchive/riscv-count-overflow/tree/main > [3]:https://github.com/riscv/riscv-smcdeleg-ssccfg > [4]:https://lore.kernel.org/all/20240217000134.3634191-1-ati...@rivosinc.com/ > [5]:https://github.com/rajnesh-kanwal/linux/wiki/Running-CTR-basic-demo-on-QEMU-RISC%E2%80%90V-Virt-machine > > Rajnesh Kanwal (6): > target/riscv: Remove obsolete sfence.vm instruction > target/riscv: Add Control Transfer Records CSR definitions. > target/riscv: Add support for Control Transfer Records extension CSRs. > target/riscv: Add support to record CTR entries. > target/riscv: Add CTR sctrclr instruction. > target/riscv: Add support to access ctrsource, ctrtarget, ctrdata > regs. > > target/riscv/cpu.c | 4 + > target/riscv/cpu.h | 14 + > target/riscv/cpu_bits.h | 154 + > target/riscv/cpu_cfg.h | 2 + > target/riscv/cpu_helper.c | 213 > target/riscv/csr.c | 312 +- > target/riscv/helper.h | 8 +- > target/riscv/insn32.decode | 2 +- > .../riscv/insn_trans/trans_privileged.c.inc | 21 +- > target/riscv/insn_trans/trans_rvi.c.inc | 27 ++ > target/riscv/op_helper.c | 117 ++- > target/riscv/translate.c | 9 + > 12 files changed, 870 insertions(+), 13 deletions(-) >
[jira] [Created] (IMPALA-13133) Failed LOAD DATA Statements Not Cleaning Up
Jason Fehr created IMPALA-13133: --- Summary: Failed LOAD DATA Statements Not Cleaning Up Key: IMPALA-13133 URL: https://issues.apache.org/jira/browse/IMPALA-13133 Project: IMPALA Issue Type: Bug Components: be Reporter: Jason Fehr When a LOAD DATA statement fails (for example, if there is a mismatch in the number of columns between the parquet files and the destination table), Impala is not cleaning up the table or the temporary hdfs directory. Thus, a "show tables" command still shows the temporary table, and the warehouse hdfs directory still contains a temporary folder. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-13133) Failed LOAD DATA Statements Not Cleaning Up
Jason Fehr created IMPALA-13133: --- Summary: Failed LOAD DATA Statements Not Cleaning Up Key: IMPALA-13133 URL: https://issues.apache.org/jira/browse/IMPALA-13133 Project: IMPALA Issue Type: Bug Components: be Reporter: Jason Fehr When a LOAD DATA statement fails (for example, if there is a mismatch in the number of columns between the parquet files and the destination table), Impala is not cleaning up the table or the temporary hdfs directory. Thus, a "show tables" command still shows the temporary table, and the warehouse hdfs directory still contains a temporary folder. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20834) A NullPointException in SubscriptionHelper.subscribe() results in the interruption of the platform-event channel subscription and events are not received
[
https://issues.apache.org/jira/browse/CAMEL-20834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason updated CAMEL-20834:
--
Description:
I appears that when the {{SubscriptionHelper}} attempts to reconnect and
resubscribe to a channel in Salesforce, that occasionally and at an
unpredictable rate, the {{subscriptionListener}} instance in
{{SubscriptionHelper.subscribe}} throws an NPE when attempting to get the
{{SUBSCRIPTION_FIELD}} from the response message from Salesforce because in
some cases that message does not contain a {{subscription}} property in the
JSON response.
This results in the component seeming to
This seems to be the offending line:
https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/streaming/SubscriptionHelper.java#L475
The reconnection seem to happen, but never actually re-subscribes to the
channel and therefore the flow of platform-events stops until the spring-boot
application is restarted.
Here is some of the associated logging:
{noformat}
[DEBUG] 2024-06-04 00:17:20,212
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #319 - SalesforceHttpClient ] -
[CHANNEL:META_HANDSHAKE]: {ext={replay=true, payload.format=true},
minimumVersion=1.0, clientId=REDACTED, supportedConnectionTypes=[long-polling],
channel=/meta/handshake, id=328, version=1.0, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{clientId=REDACTED, advice={reconnect=retry, interval=0, timeout=11},
channel=/meta/connect, id=329, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Refreshing
subscriptions to 1 channels on reconnect
[INFO ] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Subscribing to channel
/event/M1SF_SObject_Capture__e...
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[WARN ] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Connect failure:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Advice != retry, so
handshaking
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Begin handshake if not
already in progress.
[DEBUG] 2024-06-04 00:17:20,269
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[SalesforceHttpClient@f13e0a2-34 ] - [CHANNEL:META_SUBSCRIBE]:
{advice={reconnect=handshake, interval=0}, channel=/meta/subscribe, id=331,
error=403::Unknown client, successful=false}
[INFO ] 2024-06-04 00:17:20,270 org.cometd.bayeux.client.ClientSession
[SalesforceHttpClient@f13e0a2-34 ] - Exception while invoking listener
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5@704dd2c3
java.lang.NullPointerException: Cannot invoke "Object.toString()" because the
return value of "org.cometd.bayeux.Message.get(Object)" is null
at
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5.onMessage(SubscriptionHelper.java:452)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyOnMessage(AbstractClientSession.java:599)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyMessageListeners(AbstractClientSession.java:586)
at
org.cometd.common.AbstractClientSession.notifyListeners(AbstractClientSession.java:311)
at
org.cometd.common.AbstractClientSession.lambda$receive$4(AbstractClientSession.java:268)
at org.cometd.bayeux.Promise$2.succeed(Promise.java:96)
at
org.cometd.common.AsyncFoldLeft$AbstractLoop.run(AsyncFoldLeft.java:236)
at org.cometd.common.AsyncFoldLeft.run(AsyncFoldLeft.java:107)
at
org.cometd.common.AbstractClientSession.extendIncoming(AbstractClientSession.java:99)
at
org.cometd.common.AbstractClientSession.receive(AbstractCl
[jira] [Updated] (CAMEL-20834) A NullPointException in SubscriptionHelper.subscribe() results in the interruption of the platform-event channel subscription and events are not received
[
https://issues.apache.org/jira/browse/CAMEL-20834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason updated CAMEL-20834:
--
Description:
I appears that when the {{SubscriptionHelper}} attempts to reconnect and
resubscribe to a channel in Salesforce, that occasionally and at an
unpredictable rate, the {{subscriptionListene}} instance in
{{SubscriptionHelper.subscribe}} throws an NPE when attempting to get the
{{SUBSCRIPTION_FIELD}} from the response message from Salesforce because in
some cases that message does not contain a `subscription` property in the JSON
response.
This results in the component seeming to
This seems to be the offending line:
https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/streaming/SubscriptionHelper.java#L475
The reconnection seem to happen, but never actually re-subscribes to the
channel and therefore the flow of platform-events stops until the spring-boot
application is restarted.
Here is some of the associated logging:
{noformat}
[DEBUG] 2024-06-04 00:17:20,212
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #319 - SalesforceHttpClient ] -
[CHANNEL:META_HANDSHAKE]: {ext={replay=true, payload.format=true},
minimumVersion=1.0, clientId=REDACTED, supportedConnectionTypes=[long-polling],
channel=/meta/handshake, id=328, version=1.0, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{clientId=REDACTED, advice={reconnect=retry, interval=0, timeout=11},
channel=/meta/connect, id=329, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Refreshing
subscriptions to 1 channels on reconnect
[INFO ] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Subscribing to channel
/event/M1SF_SObject_Capture__e...
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[WARN ] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Connect failure:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Advice != retry, so
handshaking
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Begin handshake if not
already in progress.
[DEBUG] 2024-06-04 00:17:20,269
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[SalesforceHttpClient@f13e0a2-34 ] - [CHANNEL:META_SUBSCRIBE]:
{advice={reconnect=handshake, interval=0}, channel=/meta/subscribe, id=331,
error=403::Unknown client, successful=false}
[INFO ] 2024-06-04 00:17:20,270 org.cometd.bayeux.client.ClientSession
[SalesforceHttpClient@f13e0a2-34 ] - Exception while invoking listener
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5@704dd2c3
java.lang.NullPointerException: Cannot invoke "Object.toString()" because the
return value of "org.cometd.bayeux.Message.get(Object)" is null
at
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5.onMessage(SubscriptionHelper.java:452)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyOnMessage(AbstractClientSession.java:599)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyMessageListeners(AbstractClientSession.java:586)
at
org.cometd.common.AbstractClientSession.notifyListeners(AbstractClientSession.java:311)
at
org.cometd.common.AbstractClientSession.lambda$receive$4(AbstractClientSession.java:268)
at org.cometd.bayeux.Promise$2.succeed(Promise.java:96)
at
org.cometd.common.AsyncFoldLeft$AbstractLoop.run(AsyncFoldLeft.java:236)
at org.cometd.common.AsyncFoldLeft.run(AsyncFoldLeft.java:107)
at
org.cometd.common.AbstractClientSession.extendIncoming(AbstractClientSession.java:99)
at
org.cometd.common.AbstractClientSession.receive(AbstractCl
[jira] [Updated] (CAMEL-20834) A NullPointException in SubscriptionHelper.subscribe() results in the interruption of the platform-event channel subscription and events are not received
[
https://issues.apache.org/jira/browse/CAMEL-20834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason updated CAMEL-20834:
--
Description:
I appears that when the {{SubscriptionHelper}} attempts to reconnect and
resubscribe to a channel in Salesforce, that occasionally and at an
unpredictable rate, the {{subscriptionListene}} instance in
{{SubscriptionHelper.subscribe}} throws an NPE when attempting to get the
{{SUBSCRIPTION_FIELD}} from the response message from Salesforce because in
some cases that message does not contain a {{subscription}} property in the
JSON response.
This results in the component seeming to
This seems to be the offending line:
https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/streaming/SubscriptionHelper.java#L475
The reconnection seem to happen, but never actually re-subscribes to the
channel and therefore the flow of platform-events stops until the spring-boot
application is restarted.
Here is some of the associated logging:
{noformat}
[DEBUG] 2024-06-04 00:17:20,212
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #319 - SalesforceHttpClient ] -
[CHANNEL:META_HANDSHAKE]: {ext={replay=true, payload.format=true},
minimumVersion=1.0, clientId=REDACTED, supportedConnectionTypes=[long-polling],
channel=/meta/handshake, id=328, version=1.0, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{clientId=REDACTED, advice={reconnect=retry, interval=0, timeout=11},
channel=/meta/connect, id=329, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Refreshing
subscriptions to 1 channels on reconnect
[INFO ] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Subscribing to channel
/event/M1SF_SObject_Capture__e...
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[WARN ] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Connect failure:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Advice != retry, so
handshaking
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Begin handshake if not
already in progress.
[DEBUG] 2024-06-04 00:17:20,269
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[SalesforceHttpClient@f13e0a2-34 ] - [CHANNEL:META_SUBSCRIBE]:
{advice={reconnect=handshake, interval=0}, channel=/meta/subscribe, id=331,
error=403::Unknown client, successful=false}
[INFO ] 2024-06-04 00:17:20,270 org.cometd.bayeux.client.ClientSession
[SalesforceHttpClient@f13e0a2-34 ] - Exception while invoking listener
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5@704dd2c3
java.lang.NullPointerException: Cannot invoke "Object.toString()" because the
return value of "org.cometd.bayeux.Message.get(Object)" is null
at
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5.onMessage(SubscriptionHelper.java:452)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyOnMessage(AbstractClientSession.java:599)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyMessageListeners(AbstractClientSession.java:586)
at
org.cometd.common.AbstractClientSession.notifyListeners(AbstractClientSession.java:311)
at
org.cometd.common.AbstractClientSession.lambda$receive$4(AbstractClientSession.java:268)
at org.cometd.bayeux.Promise$2.succeed(Promise.java:96)
at
org.cometd.common.AsyncFoldLeft$AbstractLoop.run(AsyncFoldLeft.java:236)
at org.cometd.common.AsyncFoldLeft.run(AsyncFoldLeft.java:107)
at
org.cometd.common.AbstractClientSession.extendIncoming(AbstractClientSession.java:99)
at
org.cometd.common.AbstractClientSession.receive(AbstractCl
[jira] [Created] (CAMEL-20834) A NullPointException in SubscriptionHelper.subscribe() results in the interruption of the platform-event channel subscription and events are not received
Jason created CAMEL-20834:
-
Summary: A NullPointException in SubscriptionHelper.subscribe()
results in the interruption of the platform-event channel subscription and
events are not received
Key: CAMEL-20834
URL: https://issues.apache.org/jira/browse/CAMEL-20834
Project: Camel
Issue Type: Bug
Components: camel-salesforce
Affects Versions: 4.6.0, 4.5.0
Environment: Spring-Boot: 3.2.6
Camel: 4.5.0 or 4.6.0
Java: 17
Reporter: Jason
I appears that when the `SubscriptionHelper` attempts to reconnect and
resubscribe to a channel in Salesforce, that occasionally and at an
unpredictable rate, the `subscriptionListener` in
`SubscriptionHelper.subscribe` throws an NPE when attempting to get the
`SUBSCRIPTION_FIELD` from the response message from Salesforce because in some
cases that message does not contain a `subscription` property in the JSON
response.
This results in the component seeming to
This seems to be the offending line:
https://github.com/apache/camel/blob/main/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/streaming/SubscriptionHelper.java#L475
The reconnection seem to happen, but never actually re-subscribes to the
channel and therefore the flow of platform-events stops until the spring-boot
application is restarted.
Here is some of the associated logging:
{noformat}
[DEBUG] 2024-06-04 00:17:20,212
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #319 - SalesforceHttpClient ] -
[CHANNEL:META_HANDSHAKE]: {ext={replay=true, payload.format=true},
minimumVersion=1.0, clientId=REDACTED, supportedConnectionTypes=[long-polling],
channel=/meta/handshake, id=328, version=1.0, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{clientId=REDACTED, advice={reconnect=retry, interval=0, timeout=11},
channel=/meta/connect, id=329, successful=true}
[DEBUG] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Refreshing
subscriptions to 1 channels on reconnect
[INFO ] 2024-06-04 00:17:20,227
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #320 - SalesforceHttpClient ] - Subscribing to channel
/event/M1SF_SObject_Capture__e...
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - [CHANNEL:META_CONNECT]:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[WARN ] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Connect failure:
{advice={reconnect=handshake, interval=0}, channel=/meta/connect, id=330,
error=403::Unknown client, successful=false}
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Advice != retry, so
handshaking
[DEBUG] 2024-06-04 00:17:20,243
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[Camel (camel-1) thread #321 - SalesforceHttpClient ] - Begin handshake if not
already in progress.
[DEBUG] 2024-06-04 00:17:20,269
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper
[SalesforceHttpClient@f13e0a2-34 ] - [CHANNEL:META_SUBSCRIBE]:
{advice={reconnect=handshake, interval=0}, channel=/meta/subscribe, id=331,
error=403::Unknown client, successful=false}
[INFO ] 2024-06-04 00:17:20,270 org.cometd.bayeux.client.ClientSession
[SalesforceHttpClient@f13e0a2-34 ] - Exception while invoking listener
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5@704dd2c3
java.lang.NullPointerException: Cannot invoke "Object.toString()" because the
return value of "org.cometd.bayeux.Message.get(Object)" is null
at
org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper$5.onMessage(SubscriptionHelper.java:452)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyOnMessage(AbstractClientSession.java:599)
at
org.cometd.common.AbstractClientSession$AbstractSessionChannel.notifyMessageListeners(AbstractClientSession.java:586)
at
org.cometd.common.AbstractClientSession.notifyListeners(AbstractClientSession.java:311)
at
org.cometd.common.AbstractClientSession.lambda$receive$4(AbstractClientSession.java:268)
at org.cometd.bayeux.Promise$2.suc
Re: [blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access
Sorry, the ChromeStatus labels for things are a little out of sync with the launching-features documentation at the moment. I believe that you are on this step of the process: https://www.chromium.org/blink/launching-features/#deprecate Which corresponds to the "Write up plan" stage in chromestatus. At a high level, the deprecation process is intended to be front-loaded with the most scrutiny and coordination happening during the planning stage. Thanks, jason! On Tuesday, June 4, 2024 at 11:30:47 AM UTC-7 David Adrian wrote: > Ah, I got them on the "Write up plan" stage accidentally. Also, you are > correct that Debuggability has not responded yet and was still Blue. My > apologies. > > Should I ask for approvals on a different stage? None of the stages on > Deprecations seem to match an Intent to Deprecate, rather than a Developer > Trial or a traditional original trial. > > On Tue, Jun 4, 2024 at 1:14 PM Daniel Bratell wrote: > >> If so, it's not visible to me. They are all shown as grey, i.e. not >> started. Is there maybe more than one chromestatus entry and the review was >> done somewhere else? >> >> /Daniel >> On 2024-06-04 16:20, David Adrian wrote: >> >> > Can you please start (or possibly N/A) the >> Privacy/Security/Enterprise/Debuggability/Testing pills in Chromestatus? >> >> I believe it already has all the pils approved. >> >> On Tue, Jun 4, 2024 at 3:18 AM Daniel Bratell wrote: >> >>> Can you please start (or possibly N/A) the >>> Privacy/Security/Enterprise/Debuggability/Testing pills in Chromestatus? >>> >>> /Daniel >>> On 2024-06-03 21:56, 'David Adrian' via blink-dev wrote: >>> >>> > Can you please elaborate on the analysis: how low is the usage and how >>> did you check that the use is malware? >>> >>> The Blink.UseCounter.Feature for PrivateNetworkAccessNullIpAddress shows >>> <https://uma.googleplex.com/p/chrome/timeline_v2?sid=a4f412aa940bd3dd7b2bc6c960c2d91d> >>> >>> below 0.001% on all platforms. >>> >>> We've had multiple reports of malware leveraging this to attack specific >>> developer tooling frameworks, e.g. https://crbug.com/40058874. >>> >>> > Also, just to confirm, this is an intent to deprecate and remove but >>> you're planning on rolling out the removal gradually via finch, right? >>> >>> Correct. >>> >>> On Mon, Jun 3, 2024 at 1:25 PM Vladimir Levin >>> wrote: >>> >>>> >>>> >>>> On Mon, Jun 3, 2024 at 12:06 PM 'David Adrian' via blink-dev < >>>> blin...@chromium.org> wrote: >>>> >>>>> Chrome Status doesn't generate emails for the deprecation trails, only >>>>> developer trials, so I've repurposed that here. This is a Finch managed >>>>> rollout, not a developer opt-in, due to the extremely low usage that >>>>> seems >>>>> to be almost entirely malware. >>>>> >>>> >>>> Can you please elaborate on the analysis: how low is the usage and how >>>> did you check that the use is malware? >>>> >>>> Also, just to confirm, this is an intent to deprecate and remove but >>>> you're planning on rolling out the removal gradually via finch, right? >>>> >>>> Thanks! >>>> Vlad >>>> >>>> >>>>> >>>>> On Mon, Jun 3, 2024 at 12:03 PM David Adrian >>>>> wrote: >>>>> >>>>>> Contact emails l...@chromium.org >>>>>> >>>>>> Explainer None >>>>>> >>>>>> Specification https://wicg.github.io/private-network-access >>>>>> >>>>>> Summary >>>>>> >>>>>> We propose to block access to IP address 0.0.0.0 in advance of PNA >>>>>> completely rolling out. Chrome is deprecating direct access to private >>>>>> network endpoints from public websites as part of the Private Network >>>>>> Access (PNA) specification ( >>>>>> https://developer.chrome.com/blog/private-network-access-preflight/). >>>>>> Services listening on the localhost (127.0.0.0/8) are considered >>>>>> private according to the specification ( >>>>>> https://wicg.github.io/private-network-access/#ip-address-space-heading). >>>>>> >>>>>> Chrome's PNA protection (rolled o
Re: [blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access
I think this hit a chromestatus bug. A deprecation should start with approvals of the plan stage, including 3 votes from API Owners. This was incorrectly detected by chromestatus as a thread about the ship stage, which comes later. I have voted "review started" to get the "plan" stage API review gate to appear on the reviewers' dashboard. That stage already has 2 of the need cross-functional reviews approved and one pending. I'll reset the "Ship" gate so that it can be used later. I'll fix the underlying parsing bug today. Thanks, jason! On Tuesday, June 4, 2024 at 10:15:10 AM UTC-7 Daniel Bratell wrote: > If so, it's not visible to me. They are all shown as grey, i.e. not > started. Is there maybe more than one chromestatus entry and the review was > done somewhere else? > > /Daniel > On 2024-06-04 16:20, David Adrian wrote: > > > Can you please start (or possibly N/A) the > Privacy/Security/Enterprise/Debuggability/Testing pills in Chromestatus? > > I believe it already has all the pils approved. > > On Tue, Jun 4, 2024 at 3:18 AM Daniel Bratell wrote: > >> Can you please start (or possibly N/A) the >> Privacy/Security/Enterprise/Debuggability/Testing pills in Chromestatus? >> >> /Daniel >> On 2024-06-03 21:56, 'David Adrian' via blink-dev wrote: >> >> > Can you please elaborate on the analysis: how low is the usage and how >> did you check that the use is malware? >> >> The Blink.UseCounter.Feature for PrivateNetworkAccessNullIpAddress shows >> <https://uma.googleplex.com/p/chrome/timeline_v2?sid=a4f412aa940bd3dd7b2bc6c960c2d91d> >> >> below 0.001% on all platforms. >> >> We've had multiple reports of malware leveraging this to attack specific >> developer tooling frameworks, e.g. https://crbug.com/40058874. >> >> > Also, just to confirm, this is an intent to deprecate and remove but >> you're planning on rolling out the removal gradually via finch, right? >> >> Correct. >> >> On Mon, Jun 3, 2024 at 1:25 PM Vladimir Levin >> wrote: >> >>> >>> >>> On Mon, Jun 3, 2024 at 12:06 PM 'David Adrian' via blink-dev < >>> blin...@chromium.org> wrote: >>> >>>> Chrome Status doesn't generate emails for the deprecation trails, only >>>> developer trials, so I've repurposed that here. This is a Finch managed >>>> rollout, not a developer opt-in, due to the extremely low usage that seems >>>> to be almost entirely malware. >>>> >>> >>> Can you please elaborate on the analysis: how low is the usage and how >>> did you check that the use is malware? >>> >>> Also, just to confirm, this is an intent to deprecate and remove but >>> you're planning on rolling out the removal gradually via finch, right? >>> >>> Thanks! >>> Vlad >>> >>> >>>> >>>> On Mon, Jun 3, 2024 at 12:03 PM David Adrian wrote: >>>> >>>>> Contact emails l...@chromium.org >>>>> >>>>> Explainer None >>>>> >>>>> Specification https://wicg.github.io/private-network-access >>>>> >>>>> Summary >>>>> >>>>> We propose to block access to IP address 0.0.0.0 in advance of PNA >>>>> completely rolling out. Chrome is deprecating direct access to private >>>>> network endpoints from public websites as part of the Private Network >>>>> Access (PNA) specification ( >>>>> https://developer.chrome.com/blog/private-network-access-preflight/). >>>>> Services listening on the localhost (127.0.0.0/8) are considered >>>>> private according to the specification ( >>>>> https://wicg.github.io/private-network-access/#ip-address-space-heading). >>>>> Chrome's PNA protection (rolled out as part of >>>>> https://chromestatus.com/feature/5436853517811712) can be bypassed >>>>> using the IP address 0.0.0.0 to access services listening on the >>>>> localhost >>>>> on macOS and Linux. This can also be abused in DNS rebinding attacks >>>>> targeting a web application listening on the localhost. Since 0.0.0.0 is >>>>> not used in practice (and should not be used), but was overlooked during >>>>> https://chromestatus.com/feature/5436853517811712, we're deprecating >>>>> it separately from the rest of the private network requests deprecation. >>>>> This will be a Finch (expe
Re: Should I buy carbon copy cloner? Is it good enough to just use time machine? Thought anyone?
Note that the operating system volume is managed entirely by Apple on modern machines, so you only need a backup strategy for the data volume. On 3/6/24 13:42, 'E.T.' via MacVisionaries wrote: I use both. CCC will do the same basic backup as Time Machine but is very flexible if you wish to make more focused backups of specific data. Also creating restore tasks can make restoring easier. If CCC offers a trial, give it a try. From E.T.'s Keyboard... "Alone we can do so little; together we can do so much." -Helen Keller My e-Mail: ancient.ali...@icloud.com On 6/3/2024 10:15 AM, Maurice A. Mines wrote: Hello everyone, I'm trying to decide if just using time machine as a backup and restore option is better than purchasing carbon copy cloner? Because my research seems to show that one does the same thing as the other. Meaning I'm using time machine what would be the benefit to using carbon copy cloner? Bottom line, is carbon copy cloner worth the $40? Or is this expense a waste of time and money. Will time machine Restore my machine should anything bad happen? All the best Maurice mines. -- The following information is important for all members of the Mac Visionaries list. If you have any questions or concerns about the running of this list, or if you feel that a member's post is inappropriate, please contact the owners or moderators directly rather than posting on the list itself. Your Mac Visionaries list moderator is Mark Taylor. You can reach mark at: mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at caraqu...@caraquinn.com The archives for this list can be searched at: http://www.mail-archive.com/macvisionaries@googlegroups.com/ --- You received this message because you are subscribed to the Google Groups "MacVisionaries" group. To unsubscribe from this group and stop receiving emails from it, send an email to macvisionaries+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/macvisionaries/7630d01f-aaf8-43a2-9eb4-ec52676ef950%40jasonjgw.net.
Re: [PATCH 5/6] target/riscv: Add CTR sctrclr instruction.
Rajnesh Kanwal 於 2024/5/30 上午 12:09 寫道:
CTR extension adds a new instruction sctrclr to quickly
clear the recorded entries buffer.
Signed-off-by: Rajnesh Kanwal
---
target/riscv/cpu.h | 1 +
target/riscv/cpu_helper.c | 7 +++
target/riscv/insn32.decode | 1 +
target/riscv/insn_trans/trans_privileged.c.inc | 10 ++
target/riscv/op_helper.c | 5 +
5 files changed, 24 insertions(+)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index a294a5372a..fade71aa09 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -572,6 +572,7 @@ void riscv_cpu_set_mode(CPURISCVState *env, target_ulong
newpriv, bool virt_en);
void riscv_ctr_freeze(CPURISCVState *env, uint64_t freeze_mask);
void riscv_ctr_add_entry(CPURISCVState *env, target_long src, target_long dst,
uint64_t type, target_ulong prev_priv, bool
prev_virt);
+void riscv_ctr_clear(CPURISCVState *env);
void riscv_translate_init(void);
G_NORETURN void riscv_raise_exception(CPURISCVState *env,
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index e064a7306e..45502f50a7 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -704,6 +704,13 @@ void riscv_ctr_freeze(CPURISCVState *env, uint64_t
freeze_mask)
}
}
+void riscv_ctr_clear(CPURISCVState *env)
+{
+memset(env->ctr_src, 0x0, sizeof(env->ctr_src));
+memset(env->ctr_dst, 0x0, sizeof(env->ctr_dst));
+memset(env->ctr_data, 0x0, sizeof(env->ctr_data));
+}
+
static uint64_t riscv_ctr_priv_to_mask(target_ulong priv, bool virt)
{
switch (priv) {
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 9cb1a1b4ec..d3d38c7c68 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -107,6 +107,7 @@
# *** Privileged Instructions ***
ecall 0 000 0 1110011
ebreak 0001 0 000 0 1110011
+sctrclr 00010100 0 000 0 1110011
uret00000010 0 000 0 1110011
sret000100000010 0 000 0 1110011
mret001100000010 0 000 0 1110011
diff --git a/target/riscv/insn_trans/trans_privileged.c.inc
b/target/riscv/insn_trans/trans_privileged.c.inc
index 339d659151..dd9da8651f 100644
--- a/target/riscv/insn_trans/trans_privileged.c.inc
+++ b/target/riscv/insn_trans/trans_privileged.c.inc
@@ -69,6 +69,16 @@ static bool trans_ebreak(DisasContext *ctx, arg_ebreak *a)
return true;
}
+static bool trans_sctrclr(DisasContext *ctx, arg_sctrclr *a)
+{
+#ifndef CONFIG_USER_ONLY
If both of smctr and ssctr are not enabled, it is an illegal instruction.
+gen_helper_ctr_clear(tcg_env);
+return true;
+#else
+return false;
+#endif
+}
+
static bool trans_uret(DisasContext *ctx, arg_uret *a)
{
return false;
diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
index c8053d9c2f..89423c04b3 100644
--- a/target/riscv/op_helper.c
+++ b/target/riscv/op_helper.c
@@ -461,6 +461,11 @@ void helper_ctr_branch(CPURISCVState *env, target_ulong
src, target_ulong dest,
}
}
+void helper_ctr_clear(CPURISCVState *env)
+{
There should be some checks here.
The spec states:
SCTRCLR raises an illegal-instruction exception in U-mode, and a
virtual-instruction exception in VU-mode, unless CTR state enable access
restrictions apply.
I don't quite understand "unless CTR state enable access restrictions
apply" though.
+riscv_ctr_clear(env);
+}
+
void helper_wfi(CPURISCVState *env)
{
CPUState *cs = env_cpu(env);
Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
> Jiri Konecny writes: > Hi, the only change should be that you will change "vnc --connect" > with the new API we will provide and also use RDP as your client > instead of VNC. Thanks. I don't particularly care about VNC itself; I just wanted to make sure that it was known that someone does use "--connect" to do a "client-initiated" display connection. Off topic, I know, but what I really wish existed was some kind of deployment console. Early in the kickstart process, the machine being installed would contact a server, pass hardware info and wait. The server would pass back the rest of the kickstart file (after potentially getting admin input) and the installation would continue. Output would be logged in a way that the server can present to the admin, and potentially the graphical (or perhaps the text) UI could be passed through. Years ago I had hacked something implementing a little of this which just worked in %pre but it ended up being less useful than the system I use now. And really, I don't think that deployments like mine (maybe a couple hundred machines) are very common so there's probably no point. But it's an interesting problem to think about. - J< -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 6/6] target/riscv: Add support to access ctrsource, ctrtarget, ctrdata regs.
Rajnesh Kanwal 於 2024/5/30 上午 12:09 寫道:
CTR entries are accessed using ctrsource, ctrtarget and ctrdata
registers using smcsrind/sscsrind extension. This commits extends
the csrind extension to support CTR registers.
ctrsource is accessible through xireg CSR, ctrtarget is accessible
through xireg1 and ctrdata is accessible through xireg2 CSR.
CTR supports maximum depth of 256 entries which are accessed using
xiselect range 0x200 to 0x2ff.
This commits also adds properties to enable CTR extension. CTR can be
enabled using smctr=true and ssctr=true now.
Signed-off-by: Rajnesh Kanwal
---
target/riscv/cpu.c | 4 ++
target/riscv/csr.c | 153 -
2 files changed, 156 insertions(+), 1 deletion(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 30bdfc22ae..a77b1d5caf 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -193,6 +193,8 @@ const RISCVIsaExtData isa_edata_arr[] = {
ISA_EXT_DATA_ENTRY(sstvala, PRIV_VERSION_1_12_0, has_priv_1_12),
ISA_EXT_DATA_ENTRY(sstvecd, PRIV_VERSION_1_12_0, has_priv_1_12),
ISA_EXT_DATA_ENTRY(svade, PRIV_VERSION_1_11_0, ext_svade),
+ISA_EXT_DATA_ENTRY(smctr, PRIV_VERSION_1_12_0, ext_smctr),
+ISA_EXT_DATA_ENTRY(ssctr, PRIV_VERSION_1_12_0, ext_ssctr),
ISA_EXT_DATA_ENTRY(svadu, PRIV_VERSION_1_12_0, ext_svadu),
ISA_EXT_DATA_ENTRY(svinval, PRIV_VERSION_1_12_0, ext_svinval),
ISA_EXT_DATA_ENTRY(svnapot, PRIV_VERSION_1_12_0, ext_svnapot),
@@ -1473,6 +1475,8 @@ const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
MULTI_EXT_CFG_BOOL("sscsrind", ext_sscsrind, false),
MULTI_EXT_CFG_BOOL("smcdeleg", ext_smcdeleg, false),
MULTI_EXT_CFG_BOOL("ssccfg", ext_ssccfg, false),
+MULTI_EXT_CFG_BOOL("smctr", ext_smctr, false),
+MULTI_EXT_CFG_BOOL("ssctr", ext_ssctr, false),
MULTI_EXT_CFG_BOOL("zifencei", ext_zifencei, true),
MULTI_EXT_CFG_BOOL("zicsr", ext_zicsr, true),
MULTI_EXT_CFG_BOOL("zihintntl", ext_zihintntl, true),
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 888084d8e5..15b953f268 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -2291,6 +2291,11 @@ static bool xiselect_cd_range(target_ulong isel)
return (ISELECT_CD_FIRST <= isel && isel <= ISELECT_CD_LAST);
}
+static bool xiselect_ctr_range(target_ulong isel)
+{
+return (CTR_ENTRIES_FIRST <= isel && isel <= CTR_ENTRIES_LAST);
+}
+
static int rmw_iprio(target_ulong xlen,
target_ulong iselect, uint8_t *iprio,
target_ulong *val, target_ulong new_val,
@@ -2336,6 +2341,118 @@ static int rmw_iprio(target_ulong xlen,
return 0;
}
+static int rmw_xctrsource(CPURISCVState *env, int isel, target_ulong *val,
+ target_ulong new_val, target_ulong wr_mask)
I prefer naming the function as rmw_ctrsource(), since this register
name does not have a mode prefix.
+{
+/*
+ * CTR arrays are treated as circular buffers and TOS always points to next
+ * empty slot, keeping TOS - 1 always pointing to latest entry. Given entry
+ * 0 is always the latest one, traversal is a bit different here. See the
+ * below example.
+ *
+ * Depth = 16.
+ *
+ * idx[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [A] [B] [C] [D] [E] [F]
+ * TOS H
+ * entry 6 5 4 3 2 1 0 F E D C B A 9 8 7
+ */
+const uint64_t entry = isel - CTR_ENTRIES_FIRST;
+const uint64_t depth = 16 << get_field(env->sctrdepth, SCTRDEPTH_MASK);
+uint64_t idx;
+
+/* Entry greater than depth-1 is read-only zero */
+if (entry >= depth) {
+*val = 0;
val may be NULL.
+return 0;
+}
+
+idx = get_field(env->sctrstatus, SCTRSTATUS_WRPTR_MASK);
+idx = (idx - entry - 1) & (depth - 1);
+
+if (val) {
+*val = env->ctr_src[idx];
+}
+
+env->ctr_src[idx] = (env->ctr_src[idx] & ~wr_mask) | (new_val & wr_mask);
+
+return 0;
+}
+
+static int rmw_xctrtarget(CPURISCVState *env, int isel, target_ulong *val,
+ target_ulong new_val, target_ulong wr_mask)
I prefer naming the function as rmw_ctrtarget(), since this register
name does not have a mode prefix.
+{
+/*
+ * CTR arrays are treated as circular buffers and TOS always points to next
+ * empty slot, keeping TOS - 1 always pointing to latest entry. Given entry
+ * 0 is always the latest one, traversal is a bit different here. See the
+ * below example.
+ *
+ * Depth = 16.
+ *
+ * idx[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [A] [B] [C] [D] [E] [F]
+ * headH
+ * entry 6 5 4 3 2 1 0 F E D C B A 9 8 7
+ */
+const uint64_t entry = isel - CTR_ENTRIES_FIRST;
+const uint64_t depth = 16 << get_field(env->sctrdepth, SCTRDEPTH_MASK);
+uint64_t idx;
+
+/* Entry greater than depth-1
Re: [PATCH v2 02/22] iommufd: Use iommu_user_domain_alloc()
On Tue, Jun 04, 2024 at 09:51:14AM +0800, Lu Baolu wrote:
> Replace iommu_domain_alloc() with iommu_user_domain_alloc().
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/iommufd/hw_pagetable.c | 20 +---
> 1 file changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/iommu/iommufd/hw_pagetable.c
> b/drivers/iommu/iommufd/hw_pagetable.c
> index 33d142f8057d..ada05fccb36a 100644
> --- a/drivers/iommu/iommufd/hw_pagetable.c
> +++ b/drivers/iommu/iommufd/hw_pagetable.c
> @@ -127,21 +127,11 @@ iommufd_hwpt_paging_alloc(struct iommufd_ctx *ictx,
> struct iommufd_ioas *ioas,
> hwpt_paging->ioas = ioas;
> hwpt_paging->nest_parent = flags & IOMMU_HWPT_ALLOC_NEST_PARENT;
>
> - if (ops->domain_alloc_user) {
> - hwpt->domain = ops->domain_alloc_user(idev->dev, flags, NULL,
> - user_data);
> - if (IS_ERR(hwpt->domain)) {
> - rc = PTR_ERR(hwpt->domain);
> - hwpt->domain = NULL;
> - goto out_abort;
> - }
> - hwpt->domain->owner = ops;
> - } else {
> - hwpt->domain = iommu_domain_alloc(idev->dev->bus);
> - if (!hwpt->domain) {
> - rc = -ENOMEM;
> - goto out_abort;
> - }
> + hwpt->domain = iommu_user_domain_alloc(idev->dev, flags);
> + if (IS_ERR(hwpt->domain)) {
Where did the user_data go???
If you are going to wrapper the op function then all the args need to
be provided.
I'm not sure there is value in having vfio and vdpa call this
variation since they won't pass a user_data or flags?
Do you imagine there will ever be a difference between what
domain_alloc_user(dev, 0, NULL, NULL) returns from
domain_alloc_paging(dev) ?
That seems like questionable driver behavior to me.
Jason
Re: [PATCH v2 15/22] RDMA/usnic: Use iommu_paging_domain_alloc()
On Tue, Jun 04, 2024 at 09:51:27AM +0800, Lu Baolu wrote: > usnic_uiom_alloc_pd() allocates a paging domain for a given device. > In this case, iommu_domain_alloc(dev->bus) is equivalent to > iommu_paging_domain_alloc(dev). Replace it as iommu_domain_alloc() > has been deprecated. > > Signed-off-by: Lu Baolu > --- > drivers/infiniband/hw/usnic/usnic_uiom.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Acked-by: Jason Gunthorpe Jason
Re: [PATCH net-next v10 05/14] netdev: netdevice devmem allocator
On Tue, Jun 04, 2024 at 12:15:51PM -0400, Steven Rostedt wrote: > On Tue, 04 Jun 2024 12:13:15 +0200 > Paolo Abeni wrote: > > > On Thu, 2024-05-30 at 20:16 +, Mina Almasry wrote: > > > diff --git a/net/core/devmem.c b/net/core/devmem.c > > > index d82f92d7cf9ce..d5fac8edf621d 100644 > > > --- a/net/core/devmem.c > > > +++ b/net/core/devmem.c > > > @@ -32,6 +32,14 @@ static void net_devmem_dmabuf_free_chunk_owner(struct > > > gen_pool *genpool, > > > kfree(owner); > > > } > > > > > > +static inline dma_addr_t net_devmem_get_dma_addr(const struct net_iov > > > *niov) > > > > Minor nit: please no 'inline' keyword in c files. > > I'm curious. Is this a networking rule? I use 'inline' in my C code all the > time. It mostly comes from Documentation/process/coding-style.rst: 15) The inline disease -- There appears to be a common misperception that gcc has a magic "make me faster" speedup option called ``inline``. While the use of inlines can be appropriate (for example as a means of replacing macros, see Chapter 12), it very often is not. Abundant use of the inline keyword leads to a much bigger kernel, which in turn slows the system as a whole down, due to a bigger icache footprint for the CPU and simply because there is less memory available for the pagecache. Just think about it; a pagecache miss causes a disk seek, which easily takes 5 milliseconds. There are a LOT of cpu cycles that can go into these 5 milliseconds. A reasonable rule of thumb is to not put inline at functions that have more than 3 lines of code in them. An exception to this rule are the cases where a parameter is known to be a compiletime constant, and as a result of this constantness you *know* the compiler will be able to optimize most of your function away at compile time. For a good example of this later case, see the kmalloc() inline function. Often people argue that adding inline to functions that are static and used only once is always a win since there is no space tradeoff. While this is technically correct, gcc is capable of inlining these automatically without help, and the maintenance issue of removing the inline when a second user appears outweighs the potential value of the hint that tells gcc to do something it would have done anyway. Jason
Re: [PATCH net-next v10 05/14] netdev: netdevice devmem allocator
On Tue, Jun 04, 2024 at 12:15:51PM -0400, Steven Rostedt wrote: > On Tue, 04 Jun 2024 12:13:15 +0200 > Paolo Abeni wrote: > > > On Thu, 2024-05-30 at 20:16 +, Mina Almasry wrote: > > > diff --git a/net/core/devmem.c b/net/core/devmem.c > > > index d82f92d7cf9ce..d5fac8edf621d 100644 > > > --- a/net/core/devmem.c > > > +++ b/net/core/devmem.c > > > @@ -32,6 +32,14 @@ static void net_devmem_dmabuf_free_chunk_owner(struct > > > gen_pool *genpool, > > > kfree(owner); > > > } > > > > > > +static inline dma_addr_t net_devmem_get_dma_addr(const struct net_iov > > > *niov) > > > > Minor nit: please no 'inline' keyword in c files. > > I'm curious. Is this a networking rule? I use 'inline' in my C code all the > time. It mostly comes from Documentation/process/coding-style.rst: 15) The inline disease -- There appears to be a common misperception that gcc has a magic "make me faster" speedup option called ``inline``. While the use of inlines can be appropriate (for example as a means of replacing macros, see Chapter 12), it very often is not. Abundant use of the inline keyword leads to a much bigger kernel, which in turn slows the system as a whole down, due to a bigger icache footprint for the CPU and simply because there is less memory available for the pagecache. Just think about it; a pagecache miss causes a disk seek, which easily takes 5 milliseconds. There are a LOT of cpu cycles that can go into these 5 milliseconds. A reasonable rule of thumb is to not put inline at functions that have more than 3 lines of code in them. An exception to this rule are the cases where a parameter is known to be a compiletime constant, and as a result of this constantness you *know* the compiler will be able to optimize most of your function away at compile time. For a good example of this later case, see the kmalloc() inline function. Often people argue that adding inline to functions that are static and used only once is always a win since there is no space tradeoff. While this is technically correct, gcc is capable of inlining these automatically without help, and the maintenance issue of removing the inline when a second user appears outweighs the potential value of the hint that tells gcc to do something it would have done anyway. Jason
Re: [PATCH 4/6] target/riscv: Add support to record CTR entries.
This commit is missing CTR for cm.jalt, cm.jt, cm.popret, cm.popretz.
Rajnesh Kanwal 於 2024/5/30 上午 12:09 寫道:
This commit adds logic to records CTR entries of different types
and adds required hooks in TCG and interrupt/Exception logic to
record events.
This commit also adds support to invoke freeze CTR logic for breakpoint
exceptions and counter overflow interrupts.
Signed-off-by: Rajnesh Kanwal
---
target/riscv/cpu.h| 8 +
target/riscv/cpu_helper.c | 206 ++
target/riscv/helper.h | 8 +-
.../riscv/insn_trans/trans_privileged.c.inc | 6 +-
target/riscv/insn_trans/trans_rvi.c.inc | 27 +++
target/riscv/op_helper.c | 112 +-
target/riscv/translate.c | 9 +
7 files changed, 370 insertions(+), 6 deletions(-)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 3d4d5172b8..a294a5372a 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -268,6 +268,10 @@ struct CPUArchState {
uint32_t sctrstatus;
uint64_t vsctrctl;
+uint64_t ctr_src[16 << SCTRDEPTH_MAX];
+uint64_t ctr_dst[16 << SCTRDEPTH_MAX];
+uint64_t ctr_data[16 << SCTRDEPTH_MAX];
+
/* Machine and Supervisor interrupt priorities */
uint8_t miprio[64];
uint8_t siprio[64];
@@ -565,6 +569,10 @@ RISCVException smstateen_acc_ok(CPURISCVState *env, int
index, uint64_t bit);
#endif
void riscv_cpu_set_mode(CPURISCVState *env, target_ulong newpriv, bool
virt_en);
+void riscv_ctr_freeze(CPURISCVState *env, uint64_t freeze_mask);
+void riscv_ctr_add_entry(CPURISCVState *env, target_long src, target_long dst,
+ uint64_t type, target_ulong prev_priv, bool
prev_virt);
+
void riscv_translate_init(void);
G_NORETURN void riscv_raise_exception(CPURISCVState *env,
uint32_t exception, uintptr_t pc);
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index a441a03ef4..e064a7306e 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -663,6 +663,10 @@ uint64_t riscv_cpu_update_mip(CPURISCVState *env, uint64_t
mask, uint64_t value)
BQL_LOCK_GUARD();
+if (MIP_LCOFIP & value & mask) {
+riscv_ctr_freeze(env, MCTRCTL_LCOFIFRZ);
+}
+
env->mip = (env->mip & ~mask) | (value & mask);
riscv_cpu_interrupt(env);
@@ -691,6 +695,197 @@ void riscv_cpu_set_aia_ireg_rmw_fn(CPURISCVState *env,
uint32_t priv,
}
}
+void riscv_ctr_freeze(CPURISCVState *env, uint64_t freeze_mask)
+{
If both smctr and ssctr are not enabled, return immediately. Or, do the
check before invoking riscv_ctr_freeze().
+assert((freeze_mask & (~(MCTRCTL_BPFRZ | MCTRCTL_LCOFIFRZ))) == 0);
+
+if (env->mctrctl & freeze_mask) {
If the trap is handled in VS-mode, we should check vsctrctl instead:
if (((env->virt_enabled) ? env->vsctrctl : env->mctrctl) & freeze_mask)
+env->sctrstatus |= SCTRSTATUS_FROZEN;
+}
+}
+
+static uint64_t riscv_ctr_priv_to_mask(target_ulong priv, bool virt)
+{
+switch (priv) {
+case PRV_M:
+return MCTRCTL_M_ENABLE;
+case PRV_S:
+if (virt) {
+return VSCTRCTL_VS_ENABLE;
+}
+return MCTRCTL_S_ENABLE;
+case PRV_U:
+if (virt) {
+return VSCTRCTL_VU_ENABLE;
+}
+return MCTRCTL_U_ENABLE;
+}
+
+g_assert_not_reached();
+}
+
+static uint64_t riscv_ctr_get_control(CPURISCVState *env, target_long priv,
+ bool virt)
+{
+switch (priv) {
+case PRV_M:
+return env->mctrctl;
+case PRV_S:
+case PRV_U:
+if (virt) {
+return env->vsctrctl;
+}
+return env->mctrctl;
+}
+
+g_assert_not_reached();
+}
+
+/*
+ * Special cases for traps and trap returns:
+ *
+ * 1- Traps, and trap returns, between enabled modes are recorded as normal.
+ * 2- Traps from an inhibited mode to an enabled mode, and trap returns from an
+ * enabled mode back to an inhibited mode, are partially recorded. In such
+ * cases, the PC from the inhibited mode (source PC for traps, and target PC
+ * for trap returns) is 0.
+ *
+ * 3- Trap returns from an inhibited mode to an enabled mode are not recorded.
+ * Traps from an enabled mode to an inhibited mode, known as external traps,
+ * receive special handling.
+ * By default external traps are not recorded, but a handshake mechanism exists
+ * to allow partial recording. Software running in the target mode of the trap
+ * can opt-in to allowing CTR to record traps into that mode even when the mode
+ * is inhibited. The MTE, STE, and VSTE bits allow M-mode, S-mode, and
VS-mode,
+ * respectively, to opt-in. When an External Trap occurs, and xTE=1, such that
+ * x is the target privilege mode of the trap, will CTR record the trap. In
such
+ * cases, the target PC is 0.
+ */
+/*
+ * CTR
Re: [PATCH] PR c++/103338 - Add testcase for issue fixed by recent commit
On 6/4/24 11:54, Simon Martin wrote:
The case in that PR used to ICE until commit f04dc89.
Interesting, I don't remember expecting that patch to change behavior at
all.
BTW, it looks like your recent commits and emails have had
non-conventional subject lines; see
https://gcc.gnu.org/contribute.html#patches for more guidance.
For instance, the subject for this patch could be
c++: add testcase for PR103338
OK with that adjustment.
This patch simply adds
the case to the testsuite.
Successfully tested on x86_64-pc-linux-gnu.
PR c++/1033388
gcc/testsuite/ChangeLog:
* g++.dg/parse/crash73.C: New test.
---
gcc/testsuite/g++.dg/parse/crash73.C | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/parse/crash73.C
diff --git a/gcc/testsuite/g++.dg/parse/crash73.C
b/gcc/testsuite/g++.dg/parse/crash73.C
new file mode 100644
index 000..5923b98b719
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/crash73.C
@@ -0,0 +1,19 @@
+// PR c++/1033388
+// { dg-do compile { target c++11 } }
+
+template
+struct zip_view {
+ struct Iterator;
+};
+
+template
+struct zip_transform_view;
+
+template
+struct zip_view::Iterator { // { dg-error "no class template" }
+ template
+ template
+ friend class zip_transform_view::Iterator;
+};
+
+zip_view<>::Iterator iter;
[jira] [Assigned] (SOLR-17317) JAX-RS v2 APIs return XML when wt=json specified
[ https://issues.apache.org/jira/browse/SOLR-17317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski reassigned SOLR-17317: -- Assignee: Jason Gerlowski > JAX-RS v2 APIs return XML when wt=json specified > > > Key: SOLR-17317 > URL: https://issues.apache.org/jira/browse/SOLR-17317 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: v2 API >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > A mailing list user recently pointed out that certain JAX-RS v2 APIs return > XML content when "wt=json" is specified! The cause is an embarrassing > oversight in "V2ApiUtils.getMediaTypeFromWtParam": a switch-case statement > there accidentally omits "json" from its list of supported "wt" values. > We should add the missing branch of the switch-case block, and validate that > v2 APIs now respond correctly when wt=json is specified. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Review Request 75028: [mesos-build] add readme to support/mesos-build directory
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75028/ --- Review request for mesos. Repository: mesos Description --- [mesos-build] add readme to support/mesos-build directory Diffs - support/mesos-build/README.md PRE-CREATION Diff: https://reviews.apache.org/r/75028/diff/1/ Testing --- Thanks, Jason Zhou
Review Request 75027: [mesos-build] update review tidybot & docker-build.sh to support ubuntu 20.04
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75027/ --- Review request for mesos and Benjamin Mahler. Repository: mesos Description --- The reviewbot, tidybot, and our docker-build scripts have been updated to use or accomodate for ubuntu 20.04. Diffs - support/docker-build.sh 4f4019001755082c8dcbea5cb0043363940d383c support/jenkins/reviewbot.sh 349e18dfdb3786edf34300b88e7b03014ab1af59 support/mesos-tidy/Dockerfile db66a8575ba0b518ce550bf1c7cfb3d898dc9f42 Diff: https://reviews.apache.org/r/75027/diff/1/ Testing --- Thanks, Jason Zhou
Re: [PATCH v2] gcc, libcpp: Add warning switch for "#pragma once in main file" [PR89808]
g/Wpragma-once-outside-header.C
@@ -0,0 +1,5 @@
+/* { dg-do assemble } */
+/* { dg-options "-Werror=pragma-once-outside-header" } */
+
+#pragma once // { dg-error "#pragma once in main file" }
+int main() {}
diff --git a/gcc/testsuite/g++.dg/warn/Wno-pragma-once-outside-header.C
b/gcc/testsuite/g++.dg/warn/Wno-pragma-once-outside-header.C
new file mode 100644
index 000..b5be4d25a9d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wno-pragma-once-outside-header.C
@@ -0,0 +1,5 @@
+// { dg-do assemble }
+// { dg-options "-Wno-pragma-once-outside-header" }
+
+#pragma once
+int main() {}
diff --git a/gcc/testsuite/g++.dg/warn/Wpragma-once-outside-header.C
b/gcc/testsuite/g++.dg/warn/Wpragma-once-outside-header.C
new file mode 100644
index 000..ae958d3beb8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wpragma-once-outside-header.C
@@ -0,0 +1,5 @@
+// { dg-do assemble }
+// { dg-options "-Werror=pragma-once-outside-header" }
+
+#pragma once // { dg-error "#pragma once in main file" }
+int main() {}
diff --git a/libcpp/directives.cc b/libcpp/directives.cc
index 479f8c716e8..b6121a459f8 100644
--- a/libcpp/directives.cc
+++ b/libcpp/directives.cc
@@ -1588,8 +1588,12 @@ do_pragma (cpp_reader *pfile)
static void
do_pragma_once (cpp_reader *pfile)
{
- if (_cpp_in_main_source_file (pfile))
-cpp_error (pfile, CPP_DL_WARNING, "#pragma once in main file");
+ const unsigned char warn_level =
+CPP_OPTION (pfile, cpp_warn_pragma_once_outside_header);
+
+ if (warn_level && _cpp_in_main_source_file (pfile))
+cpp_error (pfile, (warn_level == 1 ? CPP_DL_WARNING : CPP_DL_ERROR),
+ "#pragma once in main file");
...it would seem better to use cpp_warning and add a cpp_warning_reason
for this diagnostic, so the normal -Werror handling (including #pragma
GCC diagnostic) takes care of it?
Jason
Re: [PATCH] Fix PR c++/111106: missing ; causes internal compiler error
On 6/4/24 05:47, Simon Martin wrote:
Hi Jason,
Thanks for the review.
On 31 May 2024, at 22:45, Jason Merrill wrote:
On 5/30/24 07:31, Simon Martin wrote:
We currently fail upon the following because an assert in
dependent_type_p
fails for f's parameter
=== cut here ===
consteval int id (int i) { return i; }
constexpr int
f (auto i) requires requires { id (i) } { return i; }
void g () { f (42); }
=== cut here ===
This patch fixes this by handling synthesized parameters for
abbreviated
function templates in that assert.
I don't see why implicit template parameters should be handled
differently from explicit ones here.
This seems more like an error-recovery issue, and I'd be open to
adding || seen_error() to that assert like in various others.
Makes sense; this is what the attached updated patch (successfully
tested on x86_64-pc-linux-gnu) does.
Is it better and OK for trunk?
OK.
Jason
Re: [BRLTTY] [issue] HID braille device very slow under certain conditions
Although I can't assist with your problem, I would suggest that, if no solution becomes available quickly, you could investigate the Asahai Linux project and its Fedora integration. This would allow you to dual boot your Mac by installing Linux alongside MacOS. On 4/6/24 04:20, Yannick PLASSIARD wrote: Dear all, For a few weeks now, I have to use a Mac to do my job. I have two braille devices: - a Focus 5 USB device - A VarioUltra 40 USB-HID device Before that, I used these two devices on Windows and Linux without any particular issues, either on a real Linux system with Brltty 6.6, or in a Linux VM hosted by Windows with the same Brltty 6.6. On MacOS however I noticed something strange with my VarioUltra device: the transfer speed of the device (sending braille input / receiving braille dots to print) is very very slow. For example, if I type characters quickly, the device will freeze for several seconds and then the characters will be processed by BRLTTY, making it very inconfortable to use. About my current setup: - Running latest macOS Sonoma on an ARM64 (m2Pro) chip - Running latest VMWare Fusion software version to use a Linux ARM64 Debian virtual machine - Connect my braille device(s) to the VM and not to the Mac, so that BRLTTY can see and interact with them. My observations: - Using the Focus 40 5th generation connected to USB, everything works very well, nothing to complain about. I’m able to read and more importantly write very quickly (typing at around 4 to 6 chars per second), and everything is responsive. - Using the VarioULTRA 40 connected to USB-HID to the same VM, things are very sluggish: typing at the same speed will result in the situation described above, i.e. slowness / freeze of the device until either a key is pressed, or a certain time. What I tried: 1) With the Focus 40: - Works well everywhere: in a VM hosted by Windows/Mac, Linux host, and MacOS Host using the screen driver. 2) With the VarioULTRA device: Works well on a Linux VM hosted by Windows and linux Host, become sluggish on a Linux VM hosted by MacOS. 3) I tried to change hypervisors, and every software behaves the same, either with UTM or VMWare Fusion (UTM can use either QEMU backend for virtualisation, or Apple’s builtin virtualisation support). 4) I A few years ago, I noticed the very same behaviour with another USB-HID device (Brilliant BI 40X) connected to a real Linux host, but unfortunately was unable to investigate furthermore as I had this device for a couple of hours. What I understood from the sources: 1) seems there is no Darwin HID support for now, so unable to test it with a compiled version for this OS with a screen driver, like I did with the Focus 40 5th Generation. 2) It seems that the async_io stack which is responsible for scheduling input/ouput events (and other things as well) does some polling so that it does not actually « sleeps » for a given time before reading data from the device. I tried to understand how timeouts are computed, to see if the issue could come from this computation, but I’m still in the early stage of understanding this stack and I currently did not find anything regarding this. Therefore, here are my questions: 1) Does anyone using an USB-HID device already experienced such behaviours in the past, and if so, did you manage to solve it? 2) Which logs would be necessary to investigate this furthermore (log categories / level)? 3) If you’re thinking about something I did not try yet, feel free to point it out, I’ll be happy to try it. Many thanks in advance for your answers, Best, Yannick ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [PATCH 3/6] target/riscv: Add support for Control Transfer Records extension CSRs.
Rajnesh Kanwal 於 2024/5/30 上午 12:09 寫道:
This commit adds support for [m|s|vs]ctrcontrol, sctrstatus and
sctrdepth CSRs handling.
Signed-off-by: Rajnesh Kanwal
---
target/riscv/cpu.h | 5 ++
target/riscv/cpu_cfg.h | 2 +
target/riscv/csr.c | 159 +
3 files changed, 166 insertions(+)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index a185e2d494..3d4d5172b8 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -263,6 +263,11 @@ struct CPUArchState {
target_ulong mcause;
target_ulong mtval; /* since: priv-1.10.0 */
+uint64_t mctrctl;
+uint32_t sctrdepth;
+uint32_t sctrstatus;
+uint64_t vsctrctl;
+
/* Machine and Supervisor interrupt priorities */
uint8_t miprio[64];
uint8_t siprio[64];
diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
index d9354dc80a..d329a65811 100644
--- a/target/riscv/cpu_cfg.h
+++ b/target/riscv/cpu_cfg.h
@@ -123,6 +123,8 @@ struct RISCVCPUConfig {
bool ext_zvfhmin;
bool ext_smaia;
bool ext_ssaia;
+bool ext_smctr;
+bool ext_ssctr;
bool ext_sscofpmf;
bool ext_smepmp;
bool rvv_ta_all_1s;
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 2f92e4b717..888084d8e5 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -621,6 +621,61 @@ static RISCVException pointer_masking(CPURISCVState *env,
int csrno)
return RISCV_EXCP_ILLEGAL_INST;
}
+/*
+ * M-mode:
+ * Without ext_smctr raise illegal inst excep.
+ * Otherwise everything is accessible to m-mode.
+ *
+ * S-mode:
+ * Without ext_ssctr or mstateen.ctr raise illegal inst excep.
+ * Otherwise everything other than mctrctl is accessible.
+ *
+ * VS-mode:
+ * Without ext_ssctr or mstateen.ctr raise illegal inst excep.
+ * Without hstateen.ctr raise virtual illegal inst excep.
+ * Otherwise allow vsctrctl, sctrstatus, 0x200-0x2ff entry range.
+ * Always raise illegal instruction exception for sctrdepth.
+ */
+static RISCVException ctr_mmode(CPURISCVState *env, int csrno)
+{
+/* Check if smctr-ext is present */
+if (riscv_cpu_cfg(env)->ext_smctr) {
+return RISCV_EXCP_NONE;
+}
+
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+static RISCVException ctr_smode(CPURISCVState *env, int csrno)
+{
+if ((env->priv == PRV_M && riscv_cpu_cfg(env)->ext_smctr) ||
+(env->priv == PRV_S && !env->virt_enabled &&
+ riscv_cpu_cfg(env)->ext_ssctr)) {
+return smstateen_acc_ok(env, 0, SMSTATEEN0_CTR);
+}
+
+if (env->priv == PRV_S && env->virt_enabled &&
+riscv_cpu_cfg(env)->ext_ssctr) {
+if (csrno == CSR_SCTRSTATUS) {
missing sctrctl?
+return smstateen_acc_ok(env, 0, SMSTATEEN0_CTR);
+}
+
+return RISCV_EXCP_VIRT_INSTRUCTION_FAULT;
+}
+
+return RISCV_EXCP_ILLEGAL_INST;
+}
I think there is no need to bind M-mode with ext_smctr, S-mode with
ext_ssctr and VS-mode with ext_ssctr, since this predicate function is
for S-mode CSRs, which are defined in both smctr and ssctr, we just need
to check at least one of ext_ssctr or ext_smctr is true.
The spec states that:
Attempts to access sctrdepth from VS-mode or VU-mode raise a
virtual-instruction exception, unless CTR state enable access
restrictions apply.
In my understanding, we should check the presence of smstateen extension
first, and
if smstateen is implemented:
* for sctrctl and sctrstatus, call smstateen_acc_ok()
* for sctrdepth, call smstateen_acc_ok(), and if there is any
exception returned, always report virtual-instruction exception.
If smstateen is not implemented:
* for sctrctl and sctrstatus, there is no check.
* for sctrdepth, I think the spec is ambiguous. What does "CTR state
enable access restrictions apply" mean when smstateen is not
implemented?
Here is the code to better understand my description.
static RISCVException ctr_smode(CPURISCVState *env, int csrno)
{
const RISCVCPUConfig *cfg = riscv_cpu_cfg(env);
if (!cfg->ext_ssctr && !cfg->ext_smctr) {
return RISCV_EXCP_ILLEGAL_INST;
}
if (riscv_cpu_cfg(env)->ext_smstateen) {
RISCVException ret = smstateen_acc_ok(env, 0, SMSTATEEN0_CTR);
if (ret != RISCV_EXCP_NONE) {
if (csrno == CSR_SCTRDEPTH && env->virt_enabled) {
return RISCV_EXCP_VIRT_INSTRUCTION_FAULT;
}
return ret;
}
} else {
/* The spec is ambiguous. */
if (csrno == CSR_SCTRDEPTH && env->virt_enabled) {
return RISCV_EXCP_VIRT_INSTRUCTION_FAULT;
}
}
return RISCV_EXCP_NONE;
}
+
+static RISCVException ctr_vsmode(CPURISCVState *env, int csrno)
+{
+if (env->priv == PRV_S && env->virt_enabled &&
+riscv_cpu_cfg(env)->ext_ssctr) {
+return smstateen_acc_ok(env, 0, SMSTATEEN0_CTR);
In riscv_csrrw_check(), an virtual-instruction exception is always
reported no matter what. Do we need this check?
+}
+
[PULL 02/20] tap: Remove qemu_using_vnet_hdr()
From: Akihiko Odaki
Since qemu_set_vnet_hdr_len() is always called when
qemu_using_vnet_hdr() is called, we can merge them and save some code.
For consistency, express that the virtio-net header is not in use by
returning 0 with qemu_get_vnet_hdr_len() instead of having a dedicated
function, qemu_get_using_vnet_hdr().
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
hw/net/e1000e.c | 1 -
hw/net/igb.c| 1 -
hw/net/net_tx_pkt.c | 4 ++--
hw/net/virtio-net.c | 3 ---
hw/net/vmxnet3.c| 2 --
include/net/net.h | 7 ---
net/dump.c | 4 +---
net/net.c | 24 +---
net/netmap.c| 5 -
net/tap.c | 28 +---
10 files changed, 5 insertions(+), 74 deletions(-)
diff --git a/hw/net/e1000e.c b/hw/net/e1000e.c
index edc101eaf6..843892ce09 100644
--- a/hw/net/e1000e.c
+++ b/hw/net/e1000e.c
@@ -352,7 +352,6 @@ e1000e_init_net_peer(E1000EState *s, PCIDevice *pci_dev,
uint8_t *macaddr)
for (i = 0; i < s->conf.peers.queues; i++) {
nc = qemu_get_subqueue(s->nic, i);
qemu_set_vnet_hdr_len(nc->peer, sizeof(struct virtio_net_hdr));
-qemu_using_vnet_hdr(nc->peer, true);
}
}
diff --git a/hw/net/igb.c b/hw/net/igb.c
index 1ef6170465..b92bba402e 100644
--- a/hw/net/igb.c
+++ b/hw/net/igb.c
@@ -349,7 +349,6 @@ igb_init_net_peer(IGBState *s, PCIDevice *pci_dev, uint8_t
*macaddr)
for (i = 0; i < s->conf.peers.queues; i++) {
nc = qemu_get_subqueue(s->nic, i);
qemu_set_vnet_hdr_len(nc->peer, sizeof(struct virtio_net_hdr));
-qemu_using_vnet_hdr(nc->peer, true);
}
}
diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c
index b7b1de816d..1f79b82b77 100644
--- a/hw/net/net_tx_pkt.c
+++ b/hw/net/net_tx_pkt.c
@@ -582,7 +582,7 @@ static void net_tx_pkt_sendv(
{
NetClientState *nc = opaque;
-if (qemu_get_using_vnet_hdr(nc->peer)) {
+if (qemu_get_vnet_hdr_len(nc->peer)) {
qemu_sendv_packet(nc, virt_iov, virt_iov_cnt);
} else {
qemu_sendv_packet(nc, iov, iov_cnt);
@@ -812,7 +812,7 @@ static bool net_tx_pkt_do_sw_fragmentation(struct NetTxPkt
*pkt,
bool net_tx_pkt_send(struct NetTxPkt *pkt, NetClientState *nc)
{
-bool offload = qemu_get_using_vnet_hdr(nc->peer);
+bool offload = qemu_get_vnet_hdr_len(nc->peer);
return net_tx_pkt_send_custom(pkt, offload, net_tx_pkt_sendv, nc);
}
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 24e5e7d347..ff600b3002 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -3778,9 +3778,6 @@ static void virtio_net_device_realize(DeviceState *dev,
Error **errp)
peer_test_vnet_hdr(n);
if (peer_has_vnet_hdr(n)) {
-for (i = 0; i < n->max_queue_pairs; i++) {
-qemu_using_vnet_hdr(qemu_get_subqueue(n->nic, i)->peer, true);
-}
n->host_hdr_len = sizeof(struct virtio_net_hdr);
} else {
n->host_hdr_len = 0;
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index 707487c636..63a9187773 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -2091,8 +2091,6 @@ static void vmxnet3_net_init(VMXNET3State *s)
if (s->peer_has_vhdr) {
qemu_set_vnet_hdr_len(qemu_get_queue(s->nic)->peer,
sizeof(struct virtio_net_hdr));
-
-qemu_using_vnet_hdr(qemu_get_queue(s->nic)->peer, 1);
}
qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
diff --git a/include/net/net.h b/include/net/net.h
index b1f9b35fcc..6fe5a0aee8 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -57,8 +57,6 @@ typedef bool (HasUfo)(NetClientState *);
typedef bool (HasUso)(NetClientState *);
typedef bool (HasVnetHdr)(NetClientState *);
typedef bool (HasVnetHdrLen)(NetClientState *, int);
-typedef bool (GetUsingVnetHdr)(NetClientState *);
-typedef void (UsingVnetHdr)(NetClientState *, bool);
typedef void (SetOffload)(NetClientState *, int, int, int, int, int, int, int);
typedef int (GetVnetHdrLen)(NetClientState *);
typedef void (SetVnetHdrLen)(NetClientState *, int);
@@ -88,10 +86,7 @@ typedef struct NetClientInfo {
HasUso *has_uso;
HasVnetHdr *has_vnet_hdr;
HasVnetHdrLen *has_vnet_hdr_len;
-GetUsingVnetHdr *get_using_vnet_hdr;
-UsingVnetHdr *using_vnet_hdr;
SetOffload *set_offload;
-GetVnetHdrLen *get_vnet_hdr_len;
SetVnetHdrLen *set_vnet_hdr_len;
SetVnetLE *set_vnet_le;
SetVnetBE *set_vnet_be;
@@ -194,8 +189,6 @@ bool qemu_has_ufo(NetClientState *nc);
bool qemu_has_uso(NetClientState *nc);
bool qemu_has_vnet_hdr(NetClientState *nc);
bool qemu_has_vnet_hdr_len(NetClientState *nc, int len);
-bool qemu_get_using_vnet_hdr(NetClientState *nc);
-void qemu_using_vnet_hdr(NetClientState *nc, bool enable);
void qemu_set_offload(NetClientState *nc, int csum, int tso4, int tso6,
int ecn, int ufo, int uso4, int uso
[PULL 13/20] virtio-net: Always set populate_hash
From: Akihiko Odaki
The member is not cleared during reset so may have a stale value.
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 8464eb4082..b423169a48 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -651,6 +651,7 @@ static void virtio_net_set_mrg_rx_bufs(VirtIONet *n, int
mergeable_rx_bufs,
n->guest_hdr_len = n->mergeable_rx_bufs ?
sizeof(struct virtio_net_hdr_mrg_rxbuf) :
sizeof(struct virtio_net_hdr);
+n->rss_data.populate_hash = false;
}
for (i = 0; i < n->max_queue_pairs; i++) {
--
2.42.0
[PULL 19/20] virtio-net: drop too short packets early
From: Alexey Dobriyan
Reproducer from https://gitlab.com/qemu-project/qemu/-/issues/1451
creates small packet (1 segment, len = 10 == n->guest_hdr_len),
then destroys queue.
"if (n->host_hdr_len != n->guest_hdr_len)" is triggered, if body creates
zero length/zero segment packet as there is nothing after guest header.
qemu_sendv_packet_async() tries to send it.
slirp discards it because it is smaller than Ethernet header,
but returns 0 because tx hooks are supposed to return total length of data.
0 is propagated upwards and is interpreted as "packet has been sent"
which is terrible because queue is being destroyed, nobody is waiting for TX
to complete and assert it triggered.
Fix is discard such empty packets instead of sending them.
Length 1 packets will go via different codepath:
virtqueue_push(q->tx_vq, elem, 0);
virtio_notify(vdev, q->tx_vq);
g_free(elem);
and aren't problematic.
Signed-off-by: Alexey Dobriyan
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 666a4e2a03..9c7e85caea 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -2708,18 +2708,14 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
out_sg = elem->out_sg;
if (out_num < 1) {
virtio_error(vdev, "virtio-net header not in first element");
-virtqueue_detach_element(q->tx_vq, elem, 0);
-g_free(elem);
-return -EINVAL;
+goto detach;
}
if (n->needs_vnet_hdr_swap) {
if (iov_to_buf(out_sg, out_num, 0, , sizeof(vhdr)) <
sizeof(vhdr)) {
virtio_error(vdev, "virtio-net header incorrect");
-virtqueue_detach_element(q->tx_vq, elem, 0);
-g_free(elem);
-return -EINVAL;
+goto detach;
}
virtio_net_hdr_swap(vdev, );
sg2[0].iov_base =
@@ -2747,6 +2743,11 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
n->guest_hdr_len, -1);
out_num = sg_num;
out_sg = sg;
+
+if (out_num < 1) {
+virtio_error(vdev, "virtio-net nothing to send");
+goto detach;
+}
}
ret = qemu_sendv_packet_async(qemu_get_subqueue(n->nic, queue_index),
@@ -2767,6 +2768,11 @@ drop:
}
}
return num_packets;
+
+detach:
+virtqueue_detach_element(q->tx_vq, elem, 0);
+g_free(elem);
+return -EINVAL;
}
static void virtio_net_tx_timer(void *opaque);
--
2.42.0
[PULL 15/20] ebpf: Fix RSS error handling
From: Akihiko Odaki
calculate_rss_hash() was using hash value 0 to tell if it calculated
a hash, but the hash value may be 0 on a rare occasion. Have a
distinct bool value for correctness.
Fixes: f3fa412de2 ("ebpf: Added eBPF RSS program.")
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
ebpf/rss.bpf.skeleton.h | 1210 +++
tools/ebpf/rss.bpf.c| 20 +-
2 files changed, 610 insertions(+), 620 deletions(-)
diff --git a/ebpf/rss.bpf.skeleton.h b/ebpf/rss.bpf.skeleton.h
index aed4ef9a03..e41ed88901 100644
--- a/ebpf/rss.bpf.skeleton.h
+++ b/ebpf/rss.bpf.skeleton.h
@@ -165,7 +165,7 @@ rss_bpf__create_skeleton(struct rss_bpf *obj)
s->progs[0].prog = >progs.tun_rss_steering_prog;
s->progs[0].link = >links.tun_rss_steering_prog;
- s->data = (void *)rss_bpf__elf_bytes(>data_sz);
+ s->data = rss_bpf__elf_bytes(>data_sz);
obj->skeleton = s;
return 0;
@@ -176,194 +176,188 @@ err:
static inline const void *rss_bpf__elf_bytes(size_t *sz)
{
- *sz = 20600;
- return (const void *)"\
+ static const char data[] __attribute__((__aligned__(8))) = "\
\x7f\x45\x4c\x46\x02\x01\x01\0\0\0\0\0\0\0\0\0\x01\0\xf7\0\x01\0\0\0\0\0\0\0\0\
-\0\0\0\0\0\0\0\0\0\0\0\x38\x4d\0\0\0\0\0\0\0\0\0\0\x40\0\0\0\0\0\x40\0\x0d\0\
-\x01\0\xbf\x19\0\0\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\x4c\xff\0\0\0\0\xbf\xa7\
-\0\0\0\0\0\0\x07\x07\0\0\x4c\xff\xff\xff\x18\x01\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
+\0\0\0\0\0\0\0\0\0\0\0\xb8\x4b\0\0\0\0\0\0\0\0\0\0\x40\0\0\0\0\0\x40\0\x0d\0\
+\x01\0\xbf\x19\0\0\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\x54\xff\0\0\0\0\xbf\xa7\
+\0\0\0\0\0\0\x07\x07\0\0\x54\xff\xff\xff\x18\x01\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\xbf\x72\0\0\0\0\0\0\x85\0\0\0\x01\0\0\0\xbf\x06\0\0\0\0\0\0\x18\x01\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\xbf\x72\0\0\0\0\0\0\x85\0\0\0\x01\0\0\0\xbf\x07\0\0\0\0\0\0\
-\x18\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\x15\x06\x61\x02\0\0\0\0\xbf\x78\0\0\
-\0\0\0\0\x15\x08\x5f\x02\0\0\0\0\x71\x61\0\0\0\0\0\0\x55\x01\x01\0\0\0\0\0\x05\
-\0\x58\x02\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xc0\xff\0\0\0\0\x7b\x1a\xb8\xff\
-\0\0\0\0\x7b\x1a\xb0\xff\0\0\0\0\x7b\x1a\xa8\xff\0\0\0\0\x7b\x1a\xa0\xff\0\0\0\
-\0\x63\x1a\x98\xff\0\0\0\0\x7b\x1a\x90\xff\0\0\0\0\x7b\x1a\x88\xff\0\0\0\0\x7b\
-\x1a\x80\xff\0\0\0\0\x7b\x1a\x78\xff\0\0\0\0\x7b\x1a\x70\xff\0\0\0\0\x7b\x1a\
-\x68\xff\0\0\0\0\x7b\x1a\x60\xff\0\0\0\0\x7b\x1a\x58\xff\0\0\0\0\x7b\x1a\x50\
-\xff\0\0\0\0\x15\x09\x47\x02\0\0\0\0\x6b\x1a\xc8\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\
-\0\x07\x03\0\0\xc8\xff\xff\xff\xbf\x91\0\0\0\0\0\0\xb7\x02\0\0\x0c\0\0\0\xb7\
+\x18\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\x15\x06\x4f\x02\0\0\0\0\xbf\x78\0\0\
+\0\0\0\0\x15\x08\x4d\x02\0\0\0\0\x71\x61\0\0\0\0\0\0\x55\x01\x01\0\0\0\0\0\x05\
+\0\x46\x02\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xc8\xff\0\0\0\0\x7b\x1a\xc0\xff\
+\0\0\0\0\x7b\x1a\xb8\xff\0\0\0\0\x7b\x1a\xb0\xff\0\0\0\0\x7b\x1a\xa8\xff\0\0\0\
+\0\x63\x1a\xa0\xff\0\0\0\0\x7b\x1a\x98\xff\0\0\0\0\x7b\x1a\x90\xff\0\0\0\0\x7b\
+\x1a\x88\xff\0\0\0\0\x7b\x1a\x80\xff\0\0\0\0\x7b\x1a\x78\xff\0\0\0\0\x7b\x1a\
+\x70\xff\0\0\0\0\x7b\x1a\x68\xff\0\0\0\0\x7b\x1a\x60\xff\0\0\0\0\x7b\x1a\x58\
+\xff\0\0\0\0\x15\x09\x35\x02\0\0\0\0\x6b\x1a\xd0\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\
+\0\x07\x03\0\0\xd0\xff\xff\xff\xbf\x91\0\0\0\0\0\0\xb7\x02\0\0\x0c\0\0\0\xb7\
\x04\0\0\x02\0\0\0\xb7\x05\0\0\0\0\0\0\x85\0\0\0\x44\0\0\0\x67\0\0\0\x20\0\0\0\
-\x77\0\0\0\x20\0\0\0\x55\0\x3c\x02\0\0\0\0\xb7\x02\0\0\x10\0\0\0\x69\xa1\xc8\
+\x77\0\0\0\x20\0\0\0\x55\0\x2a\x02\0\0\0\0\xb7\x02\0\0\x10\0\0\0\x69\xa1\xd0\
\xff\0\0\0\0\xbf\x13\0\0\0\0\0\0\xdc\x03\0\0\x10\0\0\0\x15\x03\x02\0\0\x81\0\0\
\x55\x03\x0b\0\xa8\x88\0\0\xb7\x02\0\0\x14\0\0\0\xbf\xa3\0\0\0\0\0\0\x07\x03\0\
-\0\xc8\xff\xff\xff\xbf\x91\0\0\0\0\0\0\xb7\x04\0\0\x02\0\0\0\xb7\x05\0\0\0\0\0\
-\0\x85\0\0\0\x44\0\0\0\x67\0\0\0\x20\0\0\0\x77\0\0\0\x20\0\0\0\x55\0\x2c\x02\0\
-\0\0\0\x69\xa1\xc8\xff\0\0\0\0\x15\x01\x2a\x02\0\0\0\0\x7b\x9a\x38\xff\0\0\0\0\
-\x15\x01\x56\0\x86\xdd\0\0\x55\x01\x3b\0\x08\0\0\0\xb7\x01\0\0\x01\0\0\0\x73\
-\x1a\x50\xff\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xd8\xff\0\0\0\0\x7b\x1a\xd0\
-\xff\0\0\0\0\x7b\x1a\xc8\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\0\x07\x03\0\0\xc8\xff\
-\xff\xff\x79\xa1\x38\xff\0\0\0\0\xb7\x02\0\0\0\0\0\0\xb7\x04\0\0\x14\0\0\0\xb7\
+\0\xd0\xff\xff\xff\xbf\x91\0\0\0\0\0\0\xb7\x04\0\0\x02\0\0\0\xb7\x05\0\0\0\0\0\
+\0\x85\0\0\0\x44\0\0\0\x67\0\0\0\x20\0\0\0\x77\0\0\0\x20\0\0\0\x55\0\x1a\x02\0\
+\0\0\0\x69\xa1\xd0\xff\0\0\0\0\x15\x01\x18\x02\0\0\0\0\x15\x01\x21\0\x86\xdd\0\
+\0\x7b\x9a\x48\xff\0\0\0\0\x55\x01\xf6\0\x08\0\0\0\xb7\x01\0\0\x01\0\0\0\x73\
+\x1a\x58\xff\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xe0\xff\0\0\0\0\x7b\x1a\xd8\
+\xff\0\0\0\0\x7b\x1a\xd0\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\0\x07\x03\0\0\xd0\xff\
+\xff\xff\x79\xa1\x48\xff\0\0\0\0\xb7\x02\0\0\0\0\0\0\xb7\x04\0\0\x14\0\0\0\xb7\
\x05\0\0\x01\0\0\0\x85\0\0\0\x44\0\0\0\x67\0\0\0\x20\0\0\0\x77\0\0\0\x20\0\0\0\
-\x5
[PULL 05/20] tap: Call tap_receive_iov() from tap_receive()
From: Akihiko Odaki
This will save duplicate logic found in both of tap_receive_iov() and
tap_receive().
Suggested-by: "Zhang, Chen"
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
net/tap.c | 35 +--
1 file changed, 5 insertions(+), 30 deletions(-)
diff --git a/net/tap.c b/net/tap.c
index 99c59ee468..9825518ff1 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -133,39 +133,14 @@ static ssize_t tap_receive_iov(NetClientState *nc, const
struct iovec *iov,
return tap_write_packet(s, iovp, iovcnt);
}
-static ssize_t tap_receive_raw(NetClientState *nc, const uint8_t *buf, size_t
size)
-{
-TAPState *s = DO_UPCAST(TAPState, nc, nc);
-struct iovec iov[2];
-int iovcnt = 0;
-struct virtio_net_hdr_mrg_rxbuf hdr = { };
-
-if (s->host_vnet_hdr_len) {
-iov[iovcnt].iov_base =
-iov[iovcnt].iov_len = s->host_vnet_hdr_len;
-iovcnt++;
-}
-
-iov[iovcnt].iov_base = (char *)buf;
-iov[iovcnt].iov_len = size;
-iovcnt++;
-
-return tap_write_packet(s, iov, iovcnt);
-}
-
static ssize_t tap_receive(NetClientState *nc, const uint8_t *buf, size_t size)
{
-TAPState *s = DO_UPCAST(TAPState, nc, nc);
-struct iovec iov[1];
-
-if (s->host_vnet_hdr_len && !s->using_vnet_hdr) {
-return tap_receive_raw(nc, buf, size);
-}
-
-iov[0].iov_base = (char *)buf;
-iov[0].iov_len = size;
+struct iovec iov = {
+.iov_base = (void *)buf,
+.iov_len = size
+};
-return tap_write_packet(s, iov, 1);
+return tap_receive_iov(nc, , 1);
}
#ifndef __sun__
--
2.42.0
[PULL 09/20] virtio-net: Copy header only when necessary
From: Akihiko Odaki
The copied header is only used for byte swapping.
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index a8db8bfd9c..13a17a1e5a 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -360,7 +360,8 @@ static void virtio_net_vnet_endian_status(VirtIONet *n,
uint8_t status)
* can't do it, we fallback onto fixing the headers in the core
* virtio-net code.
*/
-n->needs_vnet_hdr_swap = virtio_net_set_vnet_endian(vdev, n->nic->ncs,
+n->needs_vnet_hdr_swap = n->has_vnet_hdr &&
+ virtio_net_set_vnet_endian(vdev, n->nic->ncs,
queue_pairs, true);
} else if (virtio_net_started(n, vdev->status)) {
/* After using the device, we need to reset the network backend to
@@ -2751,7 +2752,7 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
return -EINVAL;
}
-if (n->has_vnet_hdr) {
+if (n->needs_vnet_hdr_swap) {
if (iov_to_buf(out_sg, out_num, 0, , n->guest_hdr_len) <
n->guest_hdr_len) {
virtio_error(vdev, "virtio-net header incorrect");
@@ -2759,19 +2760,16 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
g_free(elem);
return -EINVAL;
}
-if (n->needs_vnet_hdr_swap) {
-virtio_net_hdr_swap(vdev, (void *) );
-sg2[0].iov_base =
-sg2[0].iov_len = n->guest_hdr_len;
-out_num = iov_copy([1], ARRAY_SIZE(sg2) - 1,
- out_sg, out_num,
- n->guest_hdr_len, -1);
-if (out_num == VIRTQUEUE_MAX_SIZE) {
-goto drop;
-}
-out_num += 1;
-out_sg = sg2;
+virtio_net_hdr_swap(vdev, (void *) );
+sg2[0].iov_base =
+sg2[0].iov_len = n->guest_hdr_len;
+out_num = iov_copy([1], ARRAY_SIZE(sg2) - 1, out_sg, out_num,
+ n->guest_hdr_len, -1);
+if (out_num == VIRTQUEUE_MAX_SIZE) {
+goto drop;
}
+out_num += 1;
+out_sg = sg2;
}
/*
* If host wants to see the guest header as is, we can
--
2.42.0
[PULL 04/20] net: Remove receive_raw()
From: Akihiko Odaki
While netmap implements virtio-net header, it does not implement
receive_raw(). Instead of implementing receive_raw for netmap, add
virtio-net headers in the common code and use receive_iov()/receive()
instead. This also fixes the buffer size for the virtio-net header.
Fixes: fbbdbddec0 ("tap: allow extended virtio header with hash info")
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
include/net/net.h | 1 -
net/net.c | 18 --
net/tap.c | 1 -
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/include/net/net.h b/include/net/net.h
index 6fe5a0aee8..c8f679761b 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -72,7 +72,6 @@ typedef struct NetClientInfo {
NetClientDriver type;
size_t size;
NetReceive *receive;
-NetReceive *receive_raw;
NetReceiveIOV *receive_iov;
NetCanReceive *can_receive;
NetStart *start;
diff --git a/net/net.c b/net/net.c
index db096765f4..6938da05e0 100644
--- a/net/net.c
+++ b/net/net.c
@@ -787,11 +787,7 @@ static ssize_t nc_sendv_compat(NetClientState *nc, const
struct iovec *iov,
offset = iov_to_buf(iov, iovcnt, 0, buf, offset);
}
-if (flags & QEMU_NET_PACKET_FLAG_RAW && nc->info->receive_raw) {
-ret = nc->info->receive_raw(nc, buffer, offset);
-} else {
-ret = nc->info->receive(nc, buffer, offset);
-}
+ret = nc->info->receive(nc, buffer, offset);
g_free(buf);
return ret;
@@ -806,6 +802,8 @@ static ssize_t qemu_deliver_packet_iov(NetClientState
*sender,
MemReentrancyGuard *owned_reentrancy_guard;
NetClientState *nc = opaque;
int ret;
+struct virtio_net_hdr_v1_hash vnet_hdr = { };
+g_autofree struct iovec *iov_copy = NULL;
if (nc->link_down) {
@@ -824,7 +822,15 @@ static ssize_t qemu_deliver_packet_iov(NetClientState
*sender,
owned_reentrancy_guard->engaged_in_io = true;
}
-if (nc->info->receive_iov && !(flags & QEMU_NET_PACKET_FLAG_RAW)) {
+if ((flags & QEMU_NET_PACKET_FLAG_RAW) && nc->vnet_hdr_len) {
+iov_copy = g_new(struct iovec, iovcnt + 1);
+iov_copy[0].iov_base = _hdr;
+iov_copy[0].iov_len = nc->vnet_hdr_len;
+memcpy(_copy[1], iov, iovcnt * sizeof(*iov));
+iov = iov_copy;
+}
+
+if (nc->info->receive_iov) {
ret = nc->info->receive_iov(nc, iov, iovcnt);
} else {
ret = nc_sendv_compat(nc, iov, iovcnt, flags);
diff --git a/net/tap.c b/net/tap.c
index 49edf6c2b6..99c59ee468 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -360,7 +360,6 @@ static NetClientInfo net_tap_info = {
.type = NET_CLIENT_DRIVER_TAP,
.size = sizeof(TAPState),
.receive = tap_receive,
-.receive_raw = tap_receive_raw,
.receive_iov = tap_receive_iov,
.poll = tap_poll,
.cleanup = tap_cleanup,
--
2.42.0
[PULL 11/20] virtio-net: Disable RSS on reset
From: Akihiko Odaki
RSS is disabled by default.
Fixes: 590790297c ("virtio-net: implement RSS configuration command")
Signed-off-by: Akihiko Odaki
Reviewed-by: Michael Tokarev
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 70 +++--
1 file changed, 36 insertions(+), 34 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index dabfa6e7d7..345ef9a8fd 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -600,40 +600,6 @@ static void virtio_net_queue_enable(VirtIODevice *vdev,
uint32_t queue_index)
}
}
-static void virtio_net_reset(VirtIODevice *vdev)
-{
-VirtIONet *n = VIRTIO_NET(vdev);
-int i;
-
-/* Reset back to compatibility mode */
-n->promisc = 1;
-n->allmulti = 0;
-n->alluni = 0;
-n->nomulti = 0;
-n->nouni = 0;
-n->nobcast = 0;
-/* multiqueue is disabled by default */
-n->curr_queue_pairs = 1;
-timer_del(n->announce_timer.tm);
-n->announce_timer.round = 0;
-n->status &= ~VIRTIO_NET_S_ANNOUNCE;
-
-/* Flush any MAC and VLAN filter table state */
-n->mac_table.in_use = 0;
-n->mac_table.first_multi = 0;
-n->mac_table.multi_overflow = 0;
-n->mac_table.uni_overflow = 0;
-memset(n->mac_table.macs, 0, MAC_TABLE_ENTRIES * ETH_ALEN);
-memcpy(>mac[0], >nic->conf->macaddr, sizeof(n->mac));
-qemu_format_nic_info_str(qemu_get_queue(n->nic), n->mac);
-memset(n->vlans, 0, MAX_VLAN >> 3);
-
-/* Flush any async TX */
-for (i = 0; i < n->max_queue_pairs; i++) {
-flush_or_purge_queued_packets(qemu_get_subqueue(n->nic, i));
-}
-}
-
static void peer_test_vnet_hdr(VirtIONet *n)
{
NetClientState *nc = qemu_get_queue(n->nic);
@@ -3845,6 +3811,42 @@ static void virtio_net_device_unrealize(DeviceState *dev)
virtio_cleanup(vdev);
}
+static void virtio_net_reset(VirtIODevice *vdev)
+{
+VirtIONet *n = VIRTIO_NET(vdev);
+int i;
+
+/* Reset back to compatibility mode */
+n->promisc = 1;
+n->allmulti = 0;
+n->alluni = 0;
+n->nomulti = 0;
+n->nouni = 0;
+n->nobcast = 0;
+/* multiqueue is disabled by default */
+n->curr_queue_pairs = 1;
+timer_del(n->announce_timer.tm);
+n->announce_timer.round = 0;
+n->status &= ~VIRTIO_NET_S_ANNOUNCE;
+
+/* Flush any MAC and VLAN filter table state */
+n->mac_table.in_use = 0;
+n->mac_table.first_multi = 0;
+n->mac_table.multi_overflow = 0;
+n->mac_table.uni_overflow = 0;
+memset(n->mac_table.macs, 0, MAC_TABLE_ENTRIES * ETH_ALEN);
+memcpy(>mac[0], >nic->conf->macaddr, sizeof(n->mac));
+qemu_format_nic_info_str(qemu_get_queue(n->nic), n->mac);
+memset(n->vlans, 0, MAX_VLAN >> 3);
+
+/* Flush any async TX */
+for (i = 0; i < n->max_queue_pairs; i++) {
+flush_or_purge_queued_packets(qemu_get_subqueue(n->nic, i));
+}
+
+virtio_net_disable_rss(n);
+}
+
static void virtio_net_instance_init(Object *obj)
{
VirtIONet *n = VIRTIO_NET(obj);
--
2.42.0
[PULL 12/20] virtio-net: Unify the logic to update NIC state for RSS
From: Akihiko Odaki
The code to attach or detach the eBPF program to RSS were duplicated so
unify them into one function to save some code.
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 90 ++---
1 file changed, 36 insertions(+), 54 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 345ef9a8fd..8464eb4082 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1232,18 +1232,6 @@ static int virtio_net_handle_announce(VirtIONet *n,
uint8_t cmd,
}
}
-static void virtio_net_detach_epbf_rss(VirtIONet *n);
-
-static void virtio_net_disable_rss(VirtIONet *n)
-{
-if (n->rss_data.enabled) {
-trace_virtio_net_rss_disable();
-}
-n->rss_data.enabled = false;
-
-virtio_net_detach_epbf_rss(n);
-}
-
static bool virtio_net_attach_ebpf_to_backend(NICState *nic, int prog_fd)
{
NetClientState *nc = qemu_get_peer(qemu_get_queue(nic), 0);
@@ -1291,6 +1279,40 @@ static void virtio_net_detach_epbf_rss(VirtIONet *n)
virtio_net_attach_ebpf_to_backend(n->nic, -1);
}
+static void virtio_net_commit_rss_config(VirtIONet *n)
+{
+if (n->rss_data.enabled) {
+n->rss_data.enabled_software_rss = n->rss_data.populate_hash;
+if (n->rss_data.populate_hash) {
+virtio_net_detach_epbf_rss(n);
+} else if (!virtio_net_attach_epbf_rss(n)) {
+if (get_vhost_net(qemu_get_queue(n->nic)->peer)) {
+warn_report("Can't load eBPF RSS for vhost");
+} else {
+warn_report("Can't load eBPF RSS - fallback to software RSS");
+n->rss_data.enabled_software_rss = true;
+}
+}
+
+trace_virtio_net_rss_enable(n->rss_data.hash_types,
+n->rss_data.indirections_len,
+sizeof(n->rss_data.key));
+} else {
+virtio_net_detach_epbf_rss(n);
+trace_virtio_net_rss_disable();
+}
+}
+
+static void virtio_net_disable_rss(VirtIONet *n)
+{
+if (!n->rss_data.enabled) {
+return;
+}
+
+n->rss_data.enabled = false;
+virtio_net_commit_rss_config(n);
+}
+
static bool virtio_net_load_ebpf_fds(VirtIONet *n)
{
int fds[EBPF_RSS_MAX_FDS] = { [0 ... EBPF_RSS_MAX_FDS - 1] = -1};
@@ -1455,28 +1477,7 @@ static uint16_t virtio_net_handle_rss(VirtIONet *n,
goto error;
}
n->rss_data.enabled = true;
-
-if (!n->rss_data.populate_hash) {
-if (!virtio_net_attach_epbf_rss(n)) {
-/* EBPF must be loaded for vhost */
-if (get_vhost_net(qemu_get_queue(n->nic)->peer)) {
-warn_report("Can't load eBPF RSS for vhost");
-goto error;
-}
-/* fallback to software RSS */
-warn_report("Can't load eBPF RSS - fallback to software RSS");
-n->rss_data.enabled_software_rss = true;
-}
-} else {
-/* use software RSS for hash populating */
-/* and detach eBPF if was loaded before */
-virtio_net_detach_epbf_rss(n);
-n->rss_data.enabled_software_rss = true;
-}
-
-trace_virtio_net_rss_enable(n->rss_data.hash_types,
-n->rss_data.indirections_len,
-temp.b);
+virtio_net_commit_rss_config(n);
return queue_pairs;
error:
trace_virtio_net_rss_error(err_msg, err_value);
@@ -3076,26 +3077,7 @@ static int virtio_net_post_load_device(void *opaque, int
version_id)
}
}
-if (n->rss_data.enabled) {
-n->rss_data.enabled_software_rss = n->rss_data.populate_hash;
-if (!n->rss_data.populate_hash) {
-if (!virtio_net_attach_epbf_rss(n)) {
-if (get_vhost_net(qemu_get_queue(n->nic)->peer)) {
-warn_report("Can't post-load eBPF RSS for vhost");
-} else {
-warn_report("Can't post-load eBPF RSS - "
-"fallback to software RSS");
-n->rss_data.enabled_software_rss = true;
-}
-}
-}
-
-trace_virtio_net_rss_enable(n->rss_data.hash_types,
-n->rss_data.indirections_len,
-sizeof(n->rss_data.key));
-} else {
-trace_virtio_net_rss_disable();
-}
+virtio_net_commit_rss_config(n);
return 0;
}
--
2.42.0
[PULL 17/20] ebpf: Refactor tun_rss_steering_prog()
From: Akihiko Odaki
This saves branches and makes later BPF program changes easier.
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
tools/ebpf/rss.bpf.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/tools/ebpf/rss.bpf.c b/tools/ebpf/rss.bpf.c
index 77434435ac..c989cb3cd8 100644
--- a/tools/ebpf/rss.bpf.c
+++ b/tools/ebpf/rss.bpf.c
@@ -547,27 +547,23 @@ int tun_rss_steering_prog(struct __sk_buff *skb)
config = bpf_map_lookup_elem(_rss_map_configurations, );
toe = bpf_map_lookup_elem(_rss_map_toeplitz_key, );
-if (config && toe) {
-if (!config->redirect) {
-return config->default_queue;
-}
+if (!config || !toe) {
+return 0;
+}
-if (calculate_rss_hash(skb, config, toe, )) {
-__u32 table_idx = hash % config->indirections_len;
-__u16 *queue = 0;
+if (config->redirect && calculate_rss_hash(skb, config, toe, )) {
+__u32 table_idx = hash % config->indirections_len;
+__u16 *queue = 0;
-queue = bpf_map_lookup_elem(_rss_map_indirection_table,
-_idx);
+queue = bpf_map_lookup_elem(_rss_map_indirection_table,
+_idx);
-if (queue) {
-return *queue;
-}
+if (queue) {
+return *queue;
}
-
-return config->default_queue;
}
-return 0;
+return config->default_queue;
}
char _license[] SEC("license") = "GPL v2";
--
2.42.0
[PULL 16/20] ebpf: Return 0 when configuration fails
From: Akihiko Odaki
The kernel interprets the returned value as an unsigned 32-bit so -1
will mean queue 4294967295, which is awkward. Return 0 instead.
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
ebpf/rss.bpf.skeleton.h | 1532 +++
tools/ebpf/rss.bpf.c|2 +-
2 files changed, 767 insertions(+), 767 deletions(-)
diff --git a/ebpf/rss.bpf.skeleton.h b/ebpf/rss.bpf.skeleton.h
index e41ed88901..647212e5dd 100644
--- a/ebpf/rss.bpf.skeleton.h
+++ b/ebpf/rss.bpf.skeleton.h
@@ -178,786 +178,786 @@ static inline const void *rss_bpf__elf_bytes(size_t *sz)
{
static const char data[] __attribute__((__aligned__(8))) = "\
\x7f\x45\x4c\x46\x02\x01\x01\0\0\0\0\0\0\0\0\0\x01\0\xf7\0\x01\0\0\0\0\0\0\0\0\
-\0\0\0\0\0\0\0\0\0\0\0\xb8\x4b\0\0\0\0\0\0\0\0\0\0\x40\0\0\0\0\0\x40\0\x0d\0\
-\x01\0\xbf\x19\0\0\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\x54\xff\0\0\0\0\xbf\xa7\
-\0\0\0\0\0\0\x07\x07\0\0\x54\xff\xff\xff\x18\x01\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
-\xbf\x72\0\0\0\0\0\0\x85\0\0\0\x01\0\0\0\xbf\x06\0\0\0\0\0\0\x18\x01\0\0\0\0\0\
-\0\0\0\0\0\0\0\0\0\xbf\x72\0\0\0\0\0\0\x85\0\0\0\x01\0\0\0\xbf\x07\0\0\0\0\0\0\
-\x18\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\x15\x06\x4f\x02\0\0\0\0\xbf\x78\0\0\
-\0\0\0\0\x15\x08\x4d\x02\0\0\0\0\x71\x61\0\0\0\0\0\0\x55\x01\x01\0\0\0\0\0\x05\
-\0\x46\x02\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xc8\xff\0\0\0\0\x7b\x1a\xc0\xff\
-\0\0\0\0\x7b\x1a\xb8\xff\0\0\0\0\x7b\x1a\xb0\xff\0\0\0\0\x7b\x1a\xa8\xff\0\0\0\
-\0\x63\x1a\xa0\xff\0\0\0\0\x7b\x1a\x98\xff\0\0\0\0\x7b\x1a\x90\xff\0\0\0\0\x7b\
-\x1a\x88\xff\0\0\0\0\x7b\x1a\x80\xff\0\0\0\0\x7b\x1a\x78\xff\0\0\0\0\x7b\x1a\
-\x70\xff\0\0\0\0\x7b\x1a\x68\xff\0\0\0\0\x7b\x1a\x60\xff\0\0\0\0\x7b\x1a\x58\
-\xff\0\0\0\0\x15\x09\x35\x02\0\0\0\0\x6b\x1a\xd0\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\
-\0\x07\x03\0\0\xd0\xff\xff\xff\xbf\x91\0\0\0\0\0\0\xb7\x02\0\0\x0c\0\0\0\xb7\
-\x04\0\0\x02\0\0\0\xb7\x05\0\0\0\0\0\0\x85\0\0\0\x44\0\0\0\x67\0\0\0\x20\0\0\0\
-\x77\0\0\0\x20\0\0\0\x55\0\x2a\x02\0\0\0\0\xb7\x02\0\0\x10\0\0\0\x69\xa1\xd0\
-\xff\0\0\0\0\xbf\x13\0\0\0\0\0\0\xdc\x03\0\0\x10\0\0\0\x15\x03\x02\0\0\x81\0\0\
-\x55\x03\x0b\0\xa8\x88\0\0\xb7\x02\0\0\x14\0\0\0\xbf\xa3\0\0\0\0\0\0\x07\x03\0\
-\0\xd0\xff\xff\xff\xbf\x91\0\0\0\0\0\0\xb7\x04\0\0\x02\0\0\0\xb7\x05\0\0\0\0\0\
-\0\x85\0\0\0\x44\0\0\0\x67\0\0\0\x20\0\0\0\x77\0\0\0\x20\0\0\0\x55\0\x1a\x02\0\
-\0\0\0\x69\xa1\xd0\xff\0\0\0\0\x15\x01\x18\x02\0\0\0\0\x15\x01\x21\0\x86\xdd\0\
-\0\x7b\x9a\x48\xff\0\0\0\0\x55\x01\xf6\0\x08\0\0\0\xb7\x01\0\0\x01\0\0\0\x73\
-\x1a\x58\xff\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xe0\xff\0\0\0\0\x7b\x1a\xd8\
-\xff\0\0\0\0\x7b\x1a\xd0\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\0\x07\x03\0\0\xd0\xff\
-\xff\xff\x79\xa1\x48\xff\0\0\0\0\xb7\x02\0\0\0\0\0\0\xb7\x04\0\0\x14\0\0\0\xb7\
-\x05\0\0\x01\0\0\0\x85\0\0\0\x44\0\0\0\x67\0\0\0\x20\0\0\0\x77\0\0\0\x20\0\0\0\
-\x55\0\x05\x02\0\0\0\0\x69\xa1\xd6\xff\0\0\0\0\x57\x01\0\0\x3f\xff\0\0\xb7\x04\
-\0\0\x01\0\0\0\x55\x01\x01\0\0\0\0\0\xb7\x04\0\0\0\0\0\0\x61\xa1\xdc\xff\0\0\0\
-\0\x63\x1a\x64\xff\0\0\0\0\x61\xa1\xe0\xff\0\0\0\0\x63\x1a\x68\xff\0\0\0\0\x71\
-\xa9\xd9\xff\0\0\0\0\x71\xa2\xd0\xff\0\0\0\0\x67\x02\0\0\x02\0\0\0\x57\x02\0\0\
-\x3c\0\0\0\x73\x4a\x5e\xff\0\0\0\0\x05\0\xbc\0\0\0\0\0\xb7\x01\0\0\x01\0\0\0\
-\x73\x1a\x59\xff\0\0\0\0\xb7\x01\0\0\0\0\0\0\x7b\x1a\xf0\xff\0\0\0\0\x7b\x1a\
-\xe8\xff\0\0\0\0\x7b\x1a\xe0\xff\0\0\0\0\x7b\x1a\xd8\xff\0\0\0\0\x7b\x1a\xd0\
-\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\0\x07\x03\0\0\xd0\xff\xff\xff\xbf\x91\0\0\0\0\0\
-\0\xb7\x02\0\0\0\0\0\0\xb7\x04\0\0\x28\0\0\0\xb7\x05\0\0\x01\0\0\0\x85\0\0\0\
-\x44\0\0\0\x67\0\0\0\x20\0\0\0\x77\0\0\0\x20\0\0\0\x55\0\xe4\x01\0\0\0\0\xb7\
-\x03\0\0\x28\0\0\0\x7b\x9a\x48\xff\0\0\0\0\x79\xa1\xe0\xff\0\0\0\0\x63\x1a\x6c\
-\xff\0\0\0\0\x77\x01\0\0\x20\0\0\0\x63\x1a\x70\xff\0\0\0\0\x79\xa1\xd8\xff\0\0\
-\0\0\x63\x1a\x64\xff\0\0\0\0\x77\x01\0\0\x20\0\0\0\x63\x1a\x68\xff\0\0\0\0\x79\
-\xa1\xe8\xff\0\0\0\0\x63\x1a\x74\xff\0\0\0\0\x77\x01\0\0\x20\0\0\0\x63\x1a\x78\
-\xff\0\0\0\0\x79\xa1\xf0\xff\0\0\0\0\x63\x1a\x7c\xff\0\0\0\0\x77\x01\0\0\x20\0\
-\0\0\x63\x1a\x80\xff\0\0\0\0\x71\xa9\xd6\xff\0\0\0\0\x25\x09\x93\0\x3c\0\0\0\
-\xb7\x01\0\0\x01\0\0\0\x6f\x91\0\0\0\0\0\0\x18\x02\0\0\x01\0\0\0\0\0\0\0\0\x18\
-\0\x1c\x5f\x21\0\0\0\0\0\0\x55\x01\x01\0\0\0\0\0\x05\0\x8c\0\0\0\0\0\xb7\x01\0\
-\0\0\0\0\0\x6b\x1a\xfe\xff\0\0\0\0\xb7\x02\0\0\x28\0\0\0\xbf\xa1\0\0\0\0\0\0\
-\x07\x01\0\0\x94\xff\xff\xff\x7b\x1a\x20\xff\0\0\0\0\xbf\xa1\0\0\0\0\0\0\x07\
-\x01\0\0\x84\xff\xff\xff\x7b\x1a\x18\xff\0\0\0\0\xb7\x01\0\0\0\0\0\0\x7b\x1a\
-\x38\xff\0\0\0\0\x7b\x7a\x30\xff\0\0\0\0\x7b\x8a\x28\xff\0\0\0\0\xbf\xa3\0\0\0\
-\0\0\0\x07\x03\0\0\xfe\xff\xff\xff\x79\xa1\x48\xff\0\0\0\0\x7b\x2a\x40\xff\0\0\
-\0\0\xb7\x04\0\0\x02\0\0\0\xb7\x05\0\0\x01\0\0\0\x85\0\0\0\x44\0\0\0\x67\0\0\0\
-\x20\0\0\0\x77\0\0\0\x20\0\0\0\x55\0\xb2\x01\0\0\0\0\xbf\x91\0\0\0\0\0\0\x15\
-\x01\x22\0\x3c\0\0\0\x15\x01\x58\0\x2c\0\0\0\x79\xa2\x40\xff\0\0\0\0\x55\x01\
-\x59\0\x2b\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xf
[PULL 10/20] virtio-net: Shrink header byte swapping buffer
From: Akihiko Odaki
Byte swapping is only performed for the part of header shared with the
legacy standard and the buffer only needs to cover it.
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 13a17a1e5a..dabfa6e7d7 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -676,11 +676,6 @@ static void virtio_net_set_mrg_rx_bufs(VirtIONet *n, int
mergeable_rx_bufs,
n->mergeable_rx_bufs = mergeable_rx_bufs;
-/*
- * Note: when extending the vnet header, please make sure to
- * change the vnet header copying logic in virtio_net_flush_tx()
- * as well.
- */
if (version_1) {
n->guest_hdr_len = hash_report ?
sizeof(struct virtio_net_hdr_v1_hash) :
@@ -2736,7 +2731,7 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
ssize_t ret;
unsigned int out_num;
struct iovec sg[VIRTQUEUE_MAX_SIZE], sg2[VIRTQUEUE_MAX_SIZE + 1],
*out_sg;
-struct virtio_net_hdr_v1_hash vhdr;
+struct virtio_net_hdr vhdr;
elem = virtqueue_pop(q->tx_vq, sizeof(VirtQueueElement));
if (!elem) {
@@ -2753,18 +2748,18 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
}
if (n->needs_vnet_hdr_swap) {
-if (iov_to_buf(out_sg, out_num, 0, , n->guest_hdr_len) <
-n->guest_hdr_len) {
+if (iov_to_buf(out_sg, out_num, 0, , sizeof(vhdr)) <
+sizeof(vhdr)) {
virtio_error(vdev, "virtio-net header incorrect");
virtqueue_detach_element(q->tx_vq, elem, 0);
g_free(elem);
return -EINVAL;
}
-virtio_net_hdr_swap(vdev, (void *) );
+virtio_net_hdr_swap(vdev, );
sg2[0].iov_base =
-sg2[0].iov_len = n->guest_hdr_len;
+sg2[0].iov_len = sizeof(vhdr);
out_num = iov_copy([1], ARRAY_SIZE(sg2) - 1, out_sg, out_num,
- n->guest_hdr_len, -1);
+ sizeof(vhdr), -1);
if (out_num == VIRTQUEUE_MAX_SIZE) {
goto drop;
}
--
2.42.0
[PULL 18/20] ebpf: Add a separate target for skeleton
From: Akihiko Odaki This generalizes the rule to generate the skeleton and allows to add another. Signed-off-by: Akihiko Odaki Signed-off-by: Jason Wang --- tools/ebpf/Makefile.ebpf | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/tools/ebpf/Makefile.ebpf b/tools/ebpf/Makefile.ebpf index 3391e7ce08..572ca5987a 100755 --- a/tools/ebpf/Makefile.ebpf +++ b/tools/ebpf/Makefile.ebpf @@ -1,23 +1,24 @@ -OBJS = rss.bpf.o +SKELETONS = rss.bpf.skeleton.h LLVM_STRIP ?= llvm-strip CLANG ?= clang INC_FLAGS = `$(CLANG) -print-file-name=include` EXTRA_CFLAGS ?= -O2 -g -target bpf -all: $(OBJS) +all: $(SKELETONS) .PHONY: clean clean: - rm -f $(OBJS) - rm -f rss.bpf.skeleton.h + rm -f $(SKELETONS) $(SKELETONS:%.skeleton.h=%.o) -$(OBJS): %.o:%.c +%.o: %.c $(CLANG) $(INC_FLAGS) \ -D__KERNEL__ -D__ASM_SYSREG_H \ -I../include $(LINUXINCLUDE) \ $(EXTRA_CFLAGS) -c $< -o $@ $(LLVM_STRIP) -g $@ - bpftool gen skeleton rss.bpf.o > rss.bpf.skeleton.h - cp rss.bpf.skeleton.h ../../ebpf/ + +%.skeleton.h: %.o + bpftool gen skeleton $< > $@ + cp $@ ../../ebpf/ -- 2.42.0
[PULL 03/20] net: Move virtio-net header length assertion
From: Akihiko Odaki The virtio-net header length assertion should happen for any clients. Signed-off-by: Akihiko Odaki Signed-off-by: Jason Wang --- net/net.c | 5 + net/tap.c | 3 --- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/net/net.c b/net/net.c index bd51037ebf..db096765f4 100644 --- a/net/net.c +++ b/net/net.c @@ -56,6 +56,7 @@ #include "net/filter.h" #include "qapi/string-output-visitor.h" #include "qapi/qobject-input-visitor.h" +#include "standard-headers/linux/virtio_net.h" /* Net bridge is currently not supported for W32. */ #if !defined(_WIN32) @@ -550,6 +551,10 @@ void qemu_set_vnet_hdr_len(NetClientState *nc, int len) return; } +assert(len == sizeof(struct virtio_net_hdr_mrg_rxbuf) || + len == sizeof(struct virtio_net_hdr) || + len == sizeof(struct virtio_net_hdr_v1_hash)); + nc->vnet_hdr_len = len; nc->info->set_vnet_hdr_len(nc, len); } diff --git a/net/tap.c b/net/tap.c index c848844955..49edf6c2b6 100644 --- a/net/tap.c +++ b/net/tap.c @@ -267,9 +267,6 @@ static void tap_set_vnet_hdr_len(NetClientState *nc, int len) TAPState *s = DO_UPCAST(TAPState, nc, nc); assert(nc->info->type == NET_CLIENT_DRIVER_TAP); -assert(len == sizeof(struct virtio_net_hdr_mrg_rxbuf) || - len == sizeof(struct virtio_net_hdr) || - len == sizeof(struct virtio_net_hdr_v1_hash)); tap_fd_set_vnet_hdr_len(s->fd, len); s->host_vnet_hdr_len = len; -- 2.42.0
[PULL 14/20] virtio-net: Do not write hashes to peer buffer
From: Akihiko Odaki
The peer buffer is qualified with const and not meant to be modified.
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 36 +---
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index b423169a48..666a4e2a03 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1830,16 +1830,9 @@ static uint8_t virtio_net_get_hash_type(bool hasip4,
return 0xff;
}
-static void virtio_set_packet_hash(const uint8_t *buf, uint8_t report,
- uint32_t hash)
-{
-struct virtio_net_hdr_v1_hash *hdr = (void *)buf;
-hdr->hash_value = hash;
-hdr->hash_report = report;
-}
-
static int virtio_net_process_rss(NetClientState *nc, const uint8_t *buf,
- size_t size)
+ size_t size,
+ struct virtio_net_hdr_v1_hash *hdr)
{
VirtIONet *n = qemu_get_nic_opaque(nc);
unsigned int index = nc->queue_index, new_index = index;
@@ -1870,7 +1863,8 @@ static int virtio_net_process_rss(NetClientState *nc,
const uint8_t *buf,
n->rss_data.hash_types);
if (net_hash_type > NetPktRssIpV6UdpEx) {
if (n->rss_data.populate_hash) {
-virtio_set_packet_hash(buf, VIRTIO_NET_HASH_REPORT_NONE, 0);
+hdr->hash_value = VIRTIO_NET_HASH_REPORT_NONE;
+hdr->hash_report = 0;
}
return n->rss_data.redirect ? n->rss_data.default_queue : -1;
}
@@ -1878,7 +1872,8 @@ static int virtio_net_process_rss(NetClientState *nc,
const uint8_t *buf,
hash = net_rx_pkt_calc_rss_hash(pkt, net_hash_type, n->rss_data.key);
if (n->rss_data.populate_hash) {
-virtio_set_packet_hash(buf, reports[net_hash_type], hash);
+hdr->hash_value = hash;
+hdr->hash_report = reports[net_hash_type];
}
if (n->rss_data.redirect) {
@@ -1898,7 +1893,7 @@ static ssize_t virtio_net_receive_rcu(NetClientState *nc,
const uint8_t *buf,
VirtQueueElement *elems[VIRTQUEUE_MAX_SIZE];
size_t lens[VIRTQUEUE_MAX_SIZE];
struct iovec mhdr_sg[VIRTQUEUE_MAX_SIZE];
-struct virtio_net_hdr_mrg_rxbuf mhdr;
+struct virtio_net_hdr_v1_hash extra_hdr;
unsigned mhdr_cnt = 0;
size_t offset, i, guest_offset, j;
ssize_t err;
@@ -1908,7 +1903,7 @@ static ssize_t virtio_net_receive_rcu(NetClientState *nc,
const uint8_t *buf,
}
if (!no_rss && n->rss_data.enabled && n->rss_data.enabled_software_rss) {
-int index = virtio_net_process_rss(nc, buf, size);
+int index = virtio_net_process_rss(nc, buf, size, _hdr);
if (index >= 0) {
NetClientState *nc2 = qemu_get_subqueue(n->nic, index);
return virtio_net_receive_rcu(nc2, buf, size, true);
@@ -1968,15 +1963,17 @@ static ssize_t virtio_net_receive_rcu(NetClientState
*nc, const uint8_t *buf,
if (n->mergeable_rx_bufs) {
mhdr_cnt = iov_copy(mhdr_sg, ARRAY_SIZE(mhdr_sg),
sg, elem->in_num,
-offsetof(typeof(mhdr), num_buffers),
-sizeof(mhdr.num_buffers));
+offsetof(typeof(extra_hdr),
hdr.num_buffers),
+sizeof(extra_hdr.hdr.num_buffers));
}
receive_header(n, sg, elem->in_num, buf, size);
if (n->rss_data.populate_hash) {
-offset = sizeof(mhdr);
+offset = offsetof(typeof(extra_hdr), hash_value);
iov_from_buf(sg, elem->in_num, offset,
- buf + offset, n->host_hdr_len - sizeof(mhdr));
+ (char *)_hdr + offset,
+ sizeof(extra_hdr.hash_value) +
+ sizeof(extra_hdr.hash_report));
}
offset = n->host_hdr_len;
total += n->guest_hdr_len;
@@ -2006,10 +2003,11 @@ static ssize_t virtio_net_receive_rcu(NetClientState
*nc, const uint8_t *buf,
}
if (mhdr_cnt) {
-virtio_stw_p(vdev, _buffers, i);
+virtio_stw_p(vdev, _hdr.hdr.num_buffers, i);
iov_from_buf(mhdr_sg, mhdr_cnt,
0,
- _buffers, sizeof mhdr.num_buffers);
+ _hdr.hdr.num_buffers,
+ sizeof extra_hdr.hdr.num_buffers);
}
for (j = 0; j < i; j++) {
--
2.42.0
[PULL 08/20] virtio-net: Add only one queue pair when realizing
From: Akihiko Odaki
Multiqueue usage is not negotiated yet when realizing. If more than
one queue is added and the guest never requests to enable multiqueue,
the extra queues will not be deleted when unrealizing and leak.
Fixes: f9d6dbf0bf6e ("virtio-net: remove virtio queues if the guest doesn't
support multiqueue")
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 3cee2ef3ac..a8db8bfd9c 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -3743,9 +3743,7 @@ static void virtio_net_device_realize(DeviceState *dev,
Error **errp)
n->net_conf.tx_queue_size = MIN(virtio_net_max_tx_queue_size(n),
n->net_conf.tx_queue_size);
-for (i = 0; i < n->max_queue_pairs; i++) {
-virtio_net_add_queue(n, i);
-}
+virtio_net_add_queue(n, 0);
n->ctrl_vq = virtio_add_queue(vdev, 64, virtio_net_handle_ctrl);
qemu_macaddr_default_if_unset(>nic_conf.macaddr);
--
2.42.0
[PULL 07/20] virtio-net: Do not propagate ebpf-rss-fds errors
From: Akihiko Odaki
Propagating ebpf-rss-fds errors has several problems.
First, it makes device realization fail and disables the fallback to the
conventional eBPF loading.
Second, it leaks memory by making device realization fail without
freeing memory already allocated.
Third, the convention is to set an error when a function returns false,
but virtio_net_load_ebpf_fds() and virtio_net_load_ebpf() returns false
without setting an error, which is confusing.
Remove the propagation to fix these problems.
Fixes: 0524ea0510a3 ("ebpf: Added eBPF initialization by fds.")
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index ff600b3002..3cee2ef3ac 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1329,24 +1329,22 @@ static void virtio_net_detach_epbf_rss(VirtIONet *n)
virtio_net_attach_ebpf_to_backend(n->nic, -1);
}
-static bool virtio_net_load_ebpf_fds(VirtIONet *n, Error **errp)
+static bool virtio_net_load_ebpf_fds(VirtIONet *n)
{
int fds[EBPF_RSS_MAX_FDS] = { [0 ... EBPF_RSS_MAX_FDS - 1] = -1};
int ret = true;
int i = 0;
-ERRP_GUARD();
-
if (n->nr_ebpf_rss_fds != EBPF_RSS_MAX_FDS) {
-error_setg(errp,
- "Expected %d file descriptors but got %d",
- EBPF_RSS_MAX_FDS, n->nr_ebpf_rss_fds);
+warn_report("Expected %d file descriptors but got %d",
+EBPF_RSS_MAX_FDS, n->nr_ebpf_rss_fds);
return false;
}
for (i = 0; i < n->nr_ebpf_rss_fds; i++) {
-fds[i] = monitor_fd_param(monitor_cur(), n->ebpf_rss_fds[i], errp);
-if (*errp) {
+fds[i] = monitor_fd_param(monitor_cur(), n->ebpf_rss_fds[i],
+ _warn);
+if (fds[i] < 0) {
ret = false;
goto exit;
}
@@ -1355,7 +1353,7 @@ static bool virtio_net_load_ebpf_fds(VirtIONet *n, Error
**errp)
ret = ebpf_rss_load_fds(>ebpf_rss, fds[0], fds[1], fds[2], fds[3]);
exit:
-if (!ret || *errp) {
+if (!ret) {
for (i = 0; i < n->nr_ebpf_rss_fds && fds[i] != -1; i++) {
close(fds[i]);
}
@@ -1364,13 +1362,12 @@ exit:
return ret;
}
-static bool virtio_net_load_ebpf(VirtIONet *n, Error **errp)
+static bool virtio_net_load_ebpf(VirtIONet *n)
{
bool ret = false;
if (virtio_net_attach_ebpf_to_backend(n->nic, -1)) {
-if (!(n->ebpf_rss_fds
-&& virtio_net_load_ebpf_fds(n, errp))) {
+if (!(n->ebpf_rss_fds && virtio_net_load_ebpf_fds(n))) {
ret = ebpf_rss_load(>ebpf_rss);
}
}
@@ -3809,7 +3806,7 @@ static void virtio_net_device_realize(DeviceState *dev,
Error **errp)
net_rx_pkt_init(>rx_pkt);
if (virtio_has_feature(n->host_features, VIRTIO_NET_F_RSS)) {
-virtio_net_load_ebpf(n, errp);
+virtio_net_load_ebpf(n);
}
}
--
2.42.0
[PULL 20/20] ebpf: Added traces back. Changed source set for eBPF to 'system'.
From: Andrew Melnychenko
There was an issue with Qemu build with "--disable-system".
The traces could be generated and the build fails.
The traces were 'cut out' for previous patches, and overall,
the 'system' source set should be used like in pre-'eBPF blob' patches.
Signed-off-by: Andrew Melnychenko
Signed-off-by: Jason Wang
---
ebpf/ebpf_rss.c | 7 +++
ebpf/trace.h| 1 +
2 files changed, 8 insertions(+)
create mode 100644 ebpf/trace.h
diff --git a/ebpf/ebpf_rss.c b/ebpf/ebpf_rss.c
index d102f3dd09..87f0714910 100644
--- a/ebpf/ebpf_rss.c
+++ b/ebpf/ebpf_rss.c
@@ -25,6 +25,8 @@
#include "ebpf/rss.bpf.skeleton.h"
#include "ebpf/ebpf.h"
+#include "trace.h"
+
void ebpf_rss_init(struct EBPFRSSContext *ctx)
{
if (ctx != NULL) {
@@ -55,18 +57,21 @@ static bool ebpf_rss_mmap(struct EBPFRSSContext *ctx)
PROT_READ | PROT_WRITE, MAP_SHARED,
ctx->map_configuration, 0);
if (ctx->mmap_configuration == MAP_FAILED) {
+trace_ebpf_error("eBPF RSS", "can not mmap eBPF configuration array");
return false;
}
ctx->mmap_toeplitz_key = mmap(NULL, qemu_real_host_page_size(),
PROT_READ | PROT_WRITE, MAP_SHARED,
ctx->map_toeplitz_key, 0);
if (ctx->mmap_toeplitz_key == MAP_FAILED) {
+trace_ebpf_error("eBPF RSS", "can not mmap eBPF toeplitz key");
goto toeplitz_fail;
}
ctx->mmap_indirections_table = mmap(NULL, qemu_real_host_page_size(),
PROT_READ | PROT_WRITE, MAP_SHARED,
ctx->map_indirections_table, 0);
if (ctx->mmap_indirections_table == MAP_FAILED) {
+trace_ebpf_error("eBPF RSS", "can not mmap eBPF indirection table");
goto indirection_fail;
}
@@ -108,12 +113,14 @@ bool ebpf_rss_load(struct EBPFRSSContext *ctx)
rss_bpf_ctx = rss_bpf__open();
if (rss_bpf_ctx == NULL) {
+trace_ebpf_error("eBPF RSS", "can not open eBPF RSS object");
goto error;
}
bpf_program__set_type(rss_bpf_ctx->progs.tun_rss_steering_prog,
BPF_PROG_TYPE_SOCKET_FILTER);
if (rss_bpf__load(rss_bpf_ctx)) {
+trace_ebpf_error("eBPF RSS", "can not load RSS program");
goto error;
}
diff --git a/ebpf/trace.h b/ebpf/trace.h
new file mode 100644
index 00..abefc46ab1
--- /dev/null
+++ b/ebpf/trace.h
@@ -0,0 +1 @@
+#include "trace/trace-ebpf.h"
--
2.42.0
[PULL 01/20] tap: Remove tap_probe_vnet_hdr_len()
From: Akihiko Odaki
It was necessary since an Linux older than 2.6.35 may implement the
virtio-net header but may not allow to change its length. Remove it
since such an old Linux is no longer supported.
Signed-off-by: Akihiko Odaki
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
net/tap-bsd.c | 5 -
net/tap-linux.c | 20
net/tap-solaris.c | 5 -
net/tap-stub.c| 5 -
net/tap.c | 8 ++--
net/tap_int.h | 1 -
6 files changed, 2 insertions(+), 42 deletions(-)
diff --git a/net/tap-bsd.c b/net/tap-bsd.c
index 274ea7bd2c..b4c84441ba 100644
--- a/net/tap-bsd.c
+++ b/net/tap-bsd.c
@@ -217,11 +217,6 @@ int tap_probe_has_uso(int fd)
return 0;
}
-int tap_probe_vnet_hdr_len(int fd, int len)
-{
-return 0;
-}
-
void tap_fd_set_vnet_hdr_len(int fd, int len)
{
}
diff --git a/net/tap-linux.c b/net/tap-linux.c
index c7e514ecb0..1226d5fda2 100644
--- a/net/tap-linux.c
+++ b/net/tap-linux.c
@@ -185,26 +185,6 @@ int tap_probe_has_uso(int fd)
return 1;
}
-/* Verify that we can assign given length */
-int tap_probe_vnet_hdr_len(int fd, int len)
-{
-int orig;
-if (ioctl(fd, TUNGETVNETHDRSZ, ) == -1) {
-return 0;
-}
-if (ioctl(fd, TUNSETVNETHDRSZ, ) == -1) {
-return 0;
-}
-/* Restore original length: we can't handle failure. */
-if (ioctl(fd, TUNSETVNETHDRSZ, ) == -1) {
-fprintf(stderr, "TUNGETVNETHDRSZ ioctl() failed: %s. Exiting.\n",
-strerror(errno));
-abort();
-return -errno;
-}
-return 1;
-}
-
void tap_fd_set_vnet_hdr_len(int fd, int len)
{
if (ioctl(fd, TUNSETVNETHDRSZ, ) == -1) {
diff --git a/net/tap-solaris.c b/net/tap-solaris.c
index 08b13af512..51b7830bef 100644
--- a/net/tap-solaris.c
+++ b/net/tap-solaris.c
@@ -221,11 +221,6 @@ int tap_probe_has_uso(int fd)
return 0;
}
-int tap_probe_vnet_hdr_len(int fd, int len)
-{
-return 0;
-}
-
void tap_fd_set_vnet_hdr_len(int fd, int len)
{
}
diff --git a/net/tap-stub.c b/net/tap-stub.c
index 4b24f61e3a..38673434cb 100644
--- a/net/tap-stub.c
+++ b/net/tap-stub.c
@@ -52,11 +52,6 @@ int tap_probe_has_uso(int fd)
return 0;
}
-int tap_probe_vnet_hdr_len(int fd, int len)
-{
-return 0;
-}
-
void tap_fd_set_vnet_hdr_len(int fd, int len)
{
}
diff --git a/net/tap.c b/net/tap.c
index baaa2f7a9a..72ae95894f 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -259,11 +259,7 @@ static bool tap_has_vnet_hdr(NetClientState *nc)
static bool tap_has_vnet_hdr_len(NetClientState *nc, int len)
{
-TAPState *s = DO_UPCAST(TAPState, nc, nc);
-
-assert(nc->info->type == NET_CLIENT_DRIVER_TAP);
-
-return !!tap_probe_vnet_hdr_len(s->fd, len);
+return tap_has_vnet_hdr(nc);
}
static int tap_get_vnet_hdr_len(NetClientState *nc)
@@ -432,7 +428,7 @@ static TAPState *net_tap_fd_init(NetClientState *peer,
* Make sure host header length is set correctly in tap:
* it might have been modified by another instance of qemu.
*/
-if (tap_probe_vnet_hdr_len(s->fd, s->host_vnet_hdr_len)) {
+if (vnet_hdr) {
tap_fd_set_vnet_hdr_len(s->fd, s->host_vnet_hdr_len);
}
tap_read_poll(s, true);
diff --git a/net/tap_int.h b/net/tap_int.h
index 9a2175655b..8857ff299d 100644
--- a/net/tap_int.h
+++ b/net/tap_int.h
@@ -35,7 +35,6 @@ ssize_t tap_read_packet(int tapfd, uint8_t *buf, int maxlen);
void tap_set_sndbuf(int fd, const NetdevTapOptions *tap, Error **errp);
int tap_probe_vnet_hdr(int fd, Error **errp);
-int tap_probe_vnet_hdr_len(int fd, int len);
int tap_probe_has_ufo(int fd);
int tap_probe_has_uso(int fd);
void tap_fd_set_offload(int fd, int csum, int tso4, int tso6, int ecn, int ufo,
--
2.42.0
[PULL 06/20] tap: Shrink zeroed virtio-net header
From: Akihiko Odaki
tap prepends a zeroed virtio-net header when writing a packet to a
tap with virtio-net header enabled but not in use. This only happens
when s->host_vnet_hdr_len == sizeof(struct virtio_net_hdr).
Signed-off-by: Akihiko Odaki
Signed-off-by: Jason Wang
---
net/tap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tap.c b/net/tap.c
index 9825518ff1..51f7aec39d 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -119,7 +119,7 @@ static ssize_t tap_receive_iov(NetClientState *nc, const
struct iovec *iov,
TAPState *s = DO_UPCAST(TAPState, nc, nc);
const struct iovec *iovp = iov;
g_autofree struct iovec *iov_copy = NULL;
-struct virtio_net_hdr_mrg_rxbuf hdr = { };
+struct virtio_net_hdr hdr = { };
if (s->host_vnet_hdr_len && !s->using_vnet_hdr) {
iov_copy = g_new(struct iovec, iovcnt + 1);
--
2.42.0
[PULL 00/20] Net patches
The following changes since commit 3ab42e46acf867c45bc929fcc37693e327a35a24: Merge tag 'pull-ufs-20240603' of https://gitlab.com/jeuk20.kim/qemu into staging (2024-06-03 08:18:14 -0500) are available in the Git repository at: https://github.com/jasowang/qemu.git tags/net-pull-request for you to fetch changes up to dcab53611191f50cf4feabc1d8794d04afe53407: ebpf: Added traces back. Changed source set for eBPF to 'system'. (2024-06-04 15:14:26 +0800) -BEGIN PGP SIGNATURE- iQEzBAABCAAdFiEEIV1G9IJGaJ7HfzVi7wSWWzmNYhEFAmZewo4ACgkQ7wSWWzmN YhHhxgf/ZaECxru4fP8wi34XdSG/PR+BF+W5M9gZIRGrHg3vIf3/LRTpZTDccbRN Qpwtypr9O6/AWG9Os80rn7alsmMDxN8PDDNLa9T3wf5pJUQSyQ87Yy0MiuTNPSKD HKYUIfIlbFCM5WUW4huMmg98gKTgnzZMqOoRyMFZitbkR59qCm+Exws4HtXvCH68 3k4lgvnFccmzO9iIzaOUIPs+Yf04Kw/FrY0Q/6nypvqbF2W80Md6w02JMQuTLwdF Guxeg/n6g0NLvCBbkjiM2VWfTaWJYbwFSwRTAMxM/geqh7qAgGsmD0N5lPlgqRDy uAy2GvFyrwzcD0lYqf0/fRK0Go0HPA== =J70K -END PGP SIGNATURE- Akihiko Odaki (18): tap: Remove tap_probe_vnet_hdr_len() tap: Remove qemu_using_vnet_hdr() net: Move virtio-net header length assertion net: Remove receive_raw() tap: Call tap_receive_iov() from tap_receive() tap: Shrink zeroed virtio-net header virtio-net: Do not propagate ebpf-rss-fds errors virtio-net: Add only one queue pair when realizing virtio-net: Copy header only when necessary virtio-net: Shrink header byte swapping buffer virtio-net: Disable RSS on reset virtio-net: Unify the logic to update NIC state for RSS virtio-net: Always set populate_hash virtio-net: Do not write hashes to peer buffer ebpf: Fix RSS error handling ebpf: Return 0 when configuration fails ebpf: Refactor tun_rss_steering_prog() ebpf: Add a separate target for skeleton Alexey Dobriyan (1): virtio-net: drop too short packets early Andrew Melnychenko (1): ebpf: Added traces back. Changed source set for eBPF to 'system'. ebpf/ebpf_rss.c |7 + ebpf/rss.bpf.skeleton.h | 1558 +++--- ebpf/trace.h |1 + hw/net/e1000e.c |1 - hw/net/igb.c |1 - hw/net/net_tx_pkt.c |4 +- hw/net/virtio-net.c | 282 - hw/net/vmxnet3.c |2 - include/net/net.h|8 - net/dump.c |4 +- net/net.c| 47 +- net/netmap.c |5 - net/tap-bsd.c|5 - net/tap-linux.c | 20 - net/tap-solaris.c|5 - net/tap-stub.c |5 - net/tap.c| 77 +-- net/tap_int.h|1 - tools/ebpf/Makefile.ebpf | 15 +- tools/ebpf/rss.bpf.c | 44 +- 20 files changed, 968 insertions(+), 1124 deletions(-) create mode 100644 ebpf/trace.h
Re: [PATCH 0/6] target/riscv: Add support for Control Transfer Records Ext.
Smctr depends on the Smcsrind extension, Ssctr depends on the Sscsrind extension, and both Smctr and Ssctr depend upon implementation of S-mode. There should be a dependency check in riscv_cpu_validate_set_extensions(). Rajnesh Kanwal 於 2024/5/30 上午 12:09 寫道: This series enables Control Transfer Records extension support on riscv platform. This extension is similar to Arch LBR in x86 and BRBE in ARM. The Extension has been stable and the latest release can be found here [0] CTR extension depends on couple of other extensions: 1. S[m|s]csrind : The indirect CSR extension [1] which defines additional ([M|S|VS]IREG2-[M|S|VS]IREG6) register to address size limitation of RISC-V CSR address space. CTR access ctrsource, ctrtartget and ctrdata CSRs using sscsrind extension. 2. Smstateen: The mstateen bit[54] controls the access to the CTR ext to S-mode. 3. Sscofpmf: Counter overflow and privilege mode filtering. [2] The series is based on Smcdeleg/Ssccfg counter delegation extension [3] patches. CTR itself doesn't depend on counter delegation support. This rebase is basically to include the Smcsrind patches. Due to the dependency of these extensions, the following extensions must be enabled to use the control transfer records feature. "smstateen=true,sscofpmf=true,smcsrind=true,sscsrind=true,smctr=true,ssctr=true" Here is the link to a quick guide [5] to setup and run a basic perf demo on Linux to use CTR Ext. The Qemu patches can be found here: https://github.com/rajnesh-kanwal/qemu/tree/ctr_upstream The opensbi patch can be found here: https://github.com/rajnesh-kanwal/opensbi/tree/ctr_upstream The Linux kernel patches can be found here: https://github.com/rajnesh-kanwal/linux/tree/ctr_upstream [0]:https://github.com/riscv/riscv-control-transfer-records/release [1]:https://github.com/riscv/riscv-indirect-csr-access [2]:https://github.com/riscvarchive/riscv-count-overflow/tree/main [3]:https://github.com/riscv/riscv-smcdeleg-ssccfg [4]:https://lore.kernel.org/all/20240217000134.3634191-1-ati...@rivosinc.com/ [5]:https://github.com/rajnesh-kanwal/linux/wiki/Running-CTR-basic-demo-on-QEMU-RISC%E2%80%90V-Virt-machine Rajnesh Kanwal (6): target/riscv: Remove obsolete sfence.vm instruction target/riscv: Add Control Transfer Records CSR definitions. target/riscv: Add support for Control Transfer Records extension CSRs. target/riscv: Add support to record CTR entries. target/riscv: Add CTR sctrclr instruction. target/riscv: Add support to access ctrsource, ctrtarget, ctrdata regs. target/riscv/cpu.c| 4 + target/riscv/cpu.h| 14 + target/riscv/cpu_bits.h | 154 + target/riscv/cpu_cfg.h| 2 + target/riscv/cpu_helper.c | 213 target/riscv/csr.c| 312 +- target/riscv/helper.h | 8 +- target/riscv/insn32.decode| 2 +- .../riscv/insn_trans/trans_privileged.c.inc | 21 +- target/riscv/insn_trans/trans_rvi.c.inc | 27 ++ target/riscv/op_helper.c | 117 ++- target/riscv/translate.c | 9 + 12 files changed, 870 insertions(+), 13 deletions(-)
Re: [blink-dev] Intent to Extend Experiment: Compression Dictionary Transport
OK, I think that I found the problem and fixed it in ChromeStatus database. I reran the cron job that previously overwrote my simpler fix and it did not overwrite my more-complete fix. So, you should now see the "Request Trial Creation" button on the V3 OT stage, and it should still be there until you press it and submit the form. Thanks, jason! On Monday, June 3, 2024 at 12:01:10 PM UTC-7 Jason Robbins wrote: > Hmm, after I cleared out the wrong data, something filled it in again. I > will try to track down that ChromeStatus bug today. > > Thanks, > jason! > > On Sunday, June 2, 2024 at 4:59:33 PM UTC-7 Tsuyoshi Horo wrote: > >> Hi. >> >> On Sat, Jun 1, 2024 at 3:04 AM Jason Robbins wrote: >> >>> Tsuyoshi, >>> >>> Previously your third OT stage on ChromeStatus got associated with your >>> second trial on OT Console. That is probably due to a bug in ChromeStatus. >>> We'll look into that. >>> >>> To let you continue with requesting this new trial, I have cleared out >>> the trial ID for that third OT stage on ChromeStatus. Now you should see a >>> "Request Trial Creation" button on that stage that looks like: >>> https://screenshot.googleplex.com/4RZcpmCHJgxSnaT >>> >> >> Sorry, I can't find the "Request Trial Creation" button. >> I still see the "Request a trial extension" button, not the "Request >> Trial Creation". >> https://screenshot.googleplex.com/9PNnFQLkQBTVwdU >> And the "View Origin Trial" button is linked to the previous V2 Origin >> trial console URL >> <https://developer.chrome.com/origintrials/#/view_trial/3693514644397228033> >> . >> >> >> >> >>> >>> >>> You will need to change some fields in the form to indicate that this is >>> for your "V3" trial. >>> Please note that each distinct trial requires a distinct trial name with >>> an entry in >>> >>> https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/runtime_enabled_features.json5 >>> The "Request Trial Creation" form handler now checks that file when you >>> submit, so you may need to land a change to that file before you can >>> successfully submit the form. >>> >>> Thanks, >>> jason! >>> >>> >>> >>> >>> On Friday, May 31, 2024 at 6:24:37 AM UTC-7 mike...@chromium.org wrote: >>> >>>> Thanks Domenic - I agree. >>>> On 5/30/24 9:31 PM, Domenic Denicola wrote: >>>> >>>> LGTM for a new OT from 127 to 129. >>>> >>>> (Speaking generally, I think starting new OTs is better than extending >>>> existing ones, so I am glad the team has taken this route. From an >>>> ecosystem perspective, new OTs make it easier for the team to make >>>> breaking >>>> changes, and encourages OT participants to continually re-engage with the >>>> process.) >>>> >>>> On Friday, May 31, 2024 at 10:07:00 AM UTC+9 jrob...@google.com wrote: >>>> >>>>> Mike or other API Owners, still approved given that this is actually >>>>> requesting a new OT? >>>>> >>>>> Thanks, >>>>> jason! >>>>> >>>>> On Wednesday, May 29, 2024 at 5:10:54 PM UTC-7 Tsuyoshi Horo wrote: >>>>> >>>>>> Ah, sorry for the confusion. >>>>>> >>>>>> This request is for the V3 Origin Trial. >>>>>> >>>>>> V1 OT was from 117 to 122. >>>>>> V2 OT was from 122 to 125. >>>>>> And this V3 OT is from 127 to 129. >>>>>> >>>>>> >>>>>> On Thu, May 30, 2024 at 8:32 AM Patrick Meenan >>>>>> wrote: >>>>>> >>>>> Sorry, probably some confusion with the process. >>>>>>> >>>>>>> This is for the 3rd round of OT on the platform status entry >>>>>>> (CompressionDictionaryTransportV3) so "extend" may not be the right >>>>>>> terminology. V1 really ended at 122 and we had the same confusion the >>>>>>> last >>>>>>> time around and the V2 trial was created that went from 123-125 (and is >>>>>>> the >>>>>>> current active trial). >>>>>>> >>>>>>>
Re: Review Request 75023: [mesos-build] Move mesos-build to from ubuntu 16.04 to 20.04
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75023/ --- (Updated June 3, 2024, 9:48 p.m.) Review request for mesos and Benjamin Mahler. Changes --- remove comment Repository: mesos Description --- Ubuntu 16.04 docker builds were having issues with the jenkins pipeline as it was missing certain fields in /usr/include/linux/bpf.h that are present in more modern linux kernels' which were used inside the ebpf code. We will try to address this along with Ubuntu's EOL issue by upgrading to ubuntu 20.04 Diffs (updated) - support/mesos-build/ubuntu-16.04-arm.dockerfile 332009ff2b4e8d245b4b5d9c695d0f9d5ce02c44 support/mesos-build/ubuntu-16.04.dockerfile 70b269b79307dca5afac24eef880d4254236ab4c Diff: https://reviews.apache.org/r/75023/diff/4/ Changes: https://reviews.apache.org/r/75023/diff/3-4/ Testing --- Thanks, Jason Zhou
Re: [PATCH v7 4/9] C++: Support clang compatible [[musttail]] (PR83324)
On 6/3/24 15:35, Andi Kleen wrote:
On Mon, Jun 03, 2024 at 12:29:28PM -0400, Jason Merrill wrote:
On 6/3/24 11:44, Jakub Jelinek wrote:
On Mon, Jun 03, 2024 at 08:33:52AM -0700, Andi Kleen wrote:
On Mon, Jun 03, 2024 at 10:42:20AM -0400, Jason Merrill wrote:
@@ -30316,7 +30348,7 @@ cp_parser_std_attribute (cp_parser *parser, tree
attr_ns)
/* Maybe we don't expect to see any arguments for this attribute. */
const attribute_spec *as
= lookup_attribute_spec (TREE_PURPOSE (attribute));
-if (as && as->max_length == 0)
+if ((as && as->max_length == 0) || is_attribute_p ("musttail", attr_id))
This shouldn't be necessary with the attribute in the c-attribs table,
right? This patch is OK without this hunk and with the comment tweak above.
Yes I will remove it. Also the hunk above can be simplified, we don't
need the extra case anymore.
But unfortunately there's another problem (sorry I missed that earlier
but the Linaro bot pointed it out again):
This hunk:
@@ -21085,12 +21085,14 @@ tsubst_expr (tree t, tree args, tsubst_flags_t
complain, tree in_decl)
bool op = CALL_EXPR_OPERATOR_SYNTAX (t);
bool ord = CALL_EXPR_ORDERED_ARGS (t);
bool rev = CALL_EXPR_REVERSE_ARGS (t);
- if (op || ord || rev)
+ bool mtc = CALL_EXPR_MUST_TAIL_CALL (t);
+ if (op || ord || rev || mtc)
if (tree call = extract_call_expr (ret))
{
CALL_EXPR_OPERATOR_SYNTAX (call) = op;
CALL_EXPR_ORDERED_ARGS (call) = ord;
CALL_EXPR_REVERSE_ARGS (call) = rev;
+ CALL_EXPR_MUST_TAIL_CALL (call) = mtc;
}
The difference is that CALL_EXPR_MUST_TAIL_CALL is defined as:
#define CALL_EXPR_MUST_TAIL_CALL(NODE) \
(CALL_EXPR_CHECK (NODE)->base.static_flag)
while the others like:
#define CALL_EXPR_ORDERED_ARGS(NODE) \
TREE_LANG_FLAG_3 (CALL_OR_AGGR_INIT_CHECK (NODE))
where
#define CALL_OR_AGGR_INIT_CHECK(NODE) \
TREE_CHECK2 ((NODE), CALL_EXPR, AGGR_INIT_EXPR)
while
#define CALL_EXPR_CHECK(t) TREE_CHECK (t, CALL_EXPR)
(this one is defined in generated tree-check.h).
So, while the CALL_EXPR_REVERSE_ARGS etc. can be used on either
CALL_EXPR or AGGR_INIT_EXPR (the latter is a C++ specific tree code),
CALL_EXPR_MUST_TAIL_CALL is allowed only on CALL_EXPR.
AGGR_INIT_EXPR is used for C++ constructor calls, so I think
they really don't need such a flag
AGGR_INIT_EXPR is also used for functions returning a class, so I think it
is needed.
I used this variant which passes tests. It assumes that there are no
wrapped calls with this flag, but I assume that's ok.
musttail10.C should also check the case where the function called with
[[musttail]] returns a non-trivially-copyable class (e.g. that has a
destructor).
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index f6af8e1a81e4..c50fea4282e4 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -21085,14 +21085,17 @@ tsubst_expr (tree t, tree args, tsubst_flags_t
complain, tree in_decl)
bool op = CALL_EXPR_OPERATOR_SYNTAX (t);
bool ord = CALL_EXPR_ORDERED_ARGS (t);
bool rev = CALL_EXPR_REVERSE_ARGS (t);
- bool mtc = CALL_EXPR_MUST_TAIL_CALL (t);
+ bool mtc = false;
+ if (TREE_CODE (t) == CALL_EXPR)
+ mtc = CALL_EXPR_MUST_TAIL_CALL (t);
if (op || ord || rev || mtc)
if (tree call = extract_call_expr (ret))
{
CALL_EXPR_OPERATOR_SYNTAX (call) = op;
CALL_EXPR_ORDERED_ARGS (call) = ord;
CALL_EXPR_REVERSE_ARGS (call) = rev;
- CALL_EXPR_MUST_TAIL_CALL (call) = mtc;
+ if (TREE_CODE (call) == CALL_EXPR)
+ CALL_EXPR_MUST_TAIL_CALL (call) = mtc;
}
if (warning_suppressed_p (t, OPT_Wpessimizing_move))
/* This also suppresses -Wredundant-move. */
Re: Review Request 75006: [cgroups2] Introduce the DeviceManagerProcess
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75006/ --- (Updated June 3, 2024, 8:24 p.m.) Review request for mesos and Benjamin Mahler. Changes --- address reviewer feedback Repository: mesos Description --- This change introduces the DeviceManagerProcess to help facilitate device access management in cgroups2 via ebpf program file changes. The manager keeps a global state that is checkpointed on change. Device requests can be made to the manager by calling DeviceManagerProcess::deny or DeviceManagerProcess::allow. This manager will be made available to all controllers under the cgroups2 isolator, and the GPU isolator. Diffs (updated) - src/CMakeLists.txt 3973737f1f0719be98350b25abddcba81716207b src/Makefile.am 68a93674f867ca092ee035ea367f35f4580b073f src/slave/device_manager/device_manager.hpp PRE-CREATION src/slave/device_manager/device_manager.cpp PRE-CREATION src/slave/device_manager/state.hpp PRE-CREATION src/slave/device_manager/state.proto PRE-CREATION src/slave/paths.hpp 7d43e9c0170c7bcced916a892590063005133d6f src/slave/paths.cpp 3e44b636c76c01f88b00f5f8d2db39cc5fe00c1c Diff: https://reviews.apache.org/r/75006/diff/5/ Changes: https://reviews.apache.org/r/75006/diff/4-5/ Testing --- Thanks, Jason Zhou
Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
> Aoife Moloney writes: > === VNC switch to RDP for remote GUI installations === I'm curious how my usual install workflow will be affected by this change. I use the kickstart "vnc --connect" option extensively in my workflow; I may have a bunch of installs running in parallel, and they just connect and display when they are ready. I use vinagre as the vnc client. It's not a huge thing; I could come up with another workflow but that's the one I've used since before Fedora existed. The installs are fully automated and the display connection is only used so that I can see the progress and potentially interact with a machine if it encounters a problem. I guess in the worst case I could just do the install blind and ssh in if something takes too long. - J< -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Review Request 75026: [cgroups2] update device configuration EBPF program generator
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75026/ --- Review request for mesos and Benjamin Mahler. Repository: mesos Description --- In cgroups2, we want our EBPF file to only grant access to a device if it is in a cgroup's allow list and not in its deny list. This means that we need to change our previous logic that exits on the first match to now check both the allow and deny list of a cgroup before determining whether access may be granted. This patch implements the logic change, and removes functions that are no longer necessary for the DeviceProgram class. We now pass the entire allow and deny list to a configure function inside the DeviceProgram object, which will create a ebpf program with the updated logic and attempt to attach it to the cgroup. Diffs - src/linux/cgroups2.cpp 9e2ca2207a4e407fb6b07b6fbf709bbc3b397673 Diff: https://reviews.apache.org/r/75026/diff/1/ Testing --- All Cgroups2 tests pass i.e. the generated ebpf files pass the verifiers Thanks, Jason Zhou
Re: [go-cd] Assign Administrator Permissions to Role Without Manually Modifying cruise-config.xml
Hi Chad, Aravind, Thank you for the feedback. The primary context of this question is creating our own internal documentation for how to configure GoCD authentication and authorization. Since this (theoretically) only needs to be done once on initial setup, it's probably not worth the headache of documenting how to do it via the API. For the sake of simplicity, the following workflow should suffice: 1. Install GoCD. 2. Install the LDAP auth plugin. 3. Configure the LDAP connector. 4. Log in. 5. Configure the Admin role (and make sure you are in the group). 6. Navigate to the Users Management page (and make sure you have been assigned the Admin role). 7. Click the toggle in the SYSTEM ADMIN column to make your user the super-user. 8. Navigate to the Config XML page. 9. Locate the server/security/admins node (should be near the bottom of the XML document). 10. Replace "yourUserName" with "AdminRoleName". Now that I type it all out, it doesn't actually seem all that "simple", but still, good enough to get the job done. Since we are using LDAP authentication, we can manage any subsequent changes to super-user privileges via the appropriate AD group. To correct a small mistake in Chad's list of delegable permissions, the actual list is: Environments, Config Repos, Cluster Profiles, and Elastic Agent Profiles. Pipeline Groups are, sadly, not included (hence my other email thread). Thanks again, Jason On Sunday 2 June 2024 at 08:27:26 UTC-4 Aravind SV wrote: > Hello! > > Yes, what Chad says makes sense to me. > > > I don't recall discussing a UI for the tag though. There is an > API, if that helps you, Jason: > https://api.gocd.org/current/#update-system-admins > > Cheers, > Aravind > > > On Sat, 1 Jun 2024 at 10:21, Chad Wilson wrote: > >> Interesting, had not noticed that limitation (didn't know you could >> assign a role to super-admin at all!). Personally I don't know a UI-driven >> way. >> >> Looks like it was vaguely discussed as part of >> https://github.com/gocd/gocd/issues/3712 but I cannot see that >> possibility to map that within the Role Management page, nor a specific >> open issue/feature request for that. >> >> I believe there were a number of aspects of more granular auth for >> global entities <https://github.com/gocd/gocd/issues/7222> that wasn't >> necessarily completed, but I think this work was intended to reduce the >> need for super-admins in general. Keep in mind this work was mainly >> happening in H2 2019 and Thoughtworks announced closure of studios for end >> 2020 on Nov 18 2019. I believe the focus went to open sourcing pieces in H1 >> 2020 so this possibly never got to its full vision :-). >> >> Having said that, from your other post it appears you are on a very old >> GoCD version so I am not sure if what you are seeing is the same as what I >> am seeing now. >> >> In any case, you may wish to update to (or play with a trial of) a later >> version to see if a sufficient number of global entities can be directly >> delegated to roles such that the super-admin permissions are much less >> necessary than earlier, and perhaps less necessary to map to roles >> frequently. I believe it at least supports environments/cluster >> profiles/elastic profiles/pipeline groups. >> >> -Chad >> >> On Sat, Jun 1, 2024 at 4:22 AM Jason Smyth wrote: >> >>> Hi everyone, >>> >>> We are looking to improve our GoCD permissions management by using more >>> role-based permissions. >>> >>> >>> The role-based security documentation >>> <https://docs.gocd.org/19.8.0/configuration/dev_authorization.html#role-based-security> >>> states >>> that it is possible to add a role to the server's security node admin list >>> and that all users of the role will inherit admin permissions. >>> >>> We tested this and it seems to work as described, however I am unable to >>> find a mechanism for managing this within GoCD. I was only able to get it >>> working by manually editing the cruise-config.xml file. >>> >>> Am I missing something, or is this really the only way to manage >>> role-based administrative access to GoCD? >>> >>> Thanks in advance, >>> Jason >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "go-cd" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to go-cd+un...@googlegroups.com. >>> To
Re: [blink-dev] Intent to Extend Experiment: Compression Dictionary Transport
Hmm, after I cleared out the wrong data, something filled it in again. I will try to track down that ChromeStatus bug today. Thanks, jason! On Sunday, June 2, 2024 at 4:59:33 PM UTC-7 Tsuyoshi Horo wrote: > Hi. > > On Sat, Jun 1, 2024 at 3:04 AM Jason Robbins wrote: > >> Tsuyoshi, >> >> Previously your third OT stage on ChromeStatus got associated with your >> second trial on OT Console. That is probably due to a bug in ChromeStatus. >> We'll look into that. >> >> To let you continue with requesting this new trial, I have cleared out >> the trial ID for that third OT stage on ChromeStatus. Now you should see a >> "Request Trial Creation" button on that stage that looks like: >> https://screenshot.googleplex.com/4RZcpmCHJgxSnaT >> > > Sorry, I can't find the "Request Trial Creation" button. > I still see the "Request a trial extension" button, not the "Request Trial > Creation". > https://screenshot.googleplex.com/9PNnFQLkQBTVwdU > And the "View Origin Trial" button is linked to the previous V2 Origin > trial console URL > <https://developer.chrome.com/origintrials/#/view_trial/3693514644397228033> > . > > > > >> >> >> You will need to change some fields in the form to indicate that this is >> for your "V3" trial. >> Please note that each distinct trial requires a distinct trial name with >> an entry in >> >> https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/runtime_enabled_features.json5 >> The "Request Trial Creation" form handler now checks that file when you >> submit, so you may need to land a change to that file before you can >> successfully submit the form. >> >> Thanks, >> jason! >> >> >> >> >> On Friday, May 31, 2024 at 6:24:37 AM UTC-7 mike...@chromium.org wrote: >> >>> Thanks Domenic - I agree. >>> On 5/30/24 9:31 PM, Domenic Denicola wrote: >>> >>> LGTM for a new OT from 127 to 129. >>> >>> (Speaking generally, I think starting new OTs is better than extending >>> existing ones, so I am glad the team has taken this route. From an >>> ecosystem perspective, new OTs make it easier for the team to make breaking >>> changes, and encourages OT participants to continually re-engage with the >>> process.) >>> >>> On Friday, May 31, 2024 at 10:07:00 AM UTC+9 jrob...@google.com wrote: >>> >>>> Mike or other API Owners, still approved given that this is actually >>>> requesting a new OT? >>>> >>>> Thanks, >>>> jason! >>>> >>>> On Wednesday, May 29, 2024 at 5:10:54 PM UTC-7 Tsuyoshi Horo wrote: >>>> >>>>> Ah, sorry for the confusion. >>>>> >>>>> This request is for the V3 Origin Trial. >>>>> >>>>> V1 OT was from 117 to 122. >>>>> V2 OT was from 122 to 125. >>>>> And this V3 OT is from 127 to 129. >>>>> >>>>> >>>>> On Thu, May 30, 2024 at 8:32 AM Patrick Meenan >>>>> wrote: >>>>> >>>> Sorry, probably some confusion with the process. >>>>>> >>>>>> This is for the 3rd round of OT on the platform status entry >>>>>> (CompressionDictionaryTransportV3) so "extend" may not be the right >>>>>> terminology. V1 really ended at 122 and we had the same confusion the >>>>>> last >>>>>> time around and the V2 trial was created that went from 123-125 (and is >>>>>> the >>>>>> current active trial). >>>>>> >>>>>> I'll leave it to Tsuyoshi so I don't accidentally break anything, but >>>>>> I assume we need to mark the v3 trial as the active stage. >>>>>> >>>>>> On Wed, May 29, 2024 at 7:16 PM Panos Astithas >>>>>> wrote: >>>>>> >>>>> Hi Tsuyoshi, >>>>>>> >>>>>>> Is this a request to extend the V1 OT as it appears in Chromestatus >>>>>>> and in the title of this thread or are you trying to create a new V3 >>>>>>> trial >>>>>>> as it seems to be the intent based on the content of your intent? Note >>>>>>> that >>>>>>> V1 ended at M125, so teh extension would be for 4 milestones. >>>>&g
Purpose of IndexUpgraderTool
Hey all, I was poking around the ref-guide a bit recently and noticed our page on the "IndexUpgraderTool" that Lucene produces. [1] AFAICT, the page doesn't hint at when/why a user might want to use the IndexUpgraderTool. Maybe at one point the tool might've been preferred to loading the index in an upgraded Solr version, but I haven't heard of anyone doing that in the last few years. Is this something we expect users to still do? If so, for what usecase? And if not - should we drop it from the ref-guide - it seems like it might confuse folks since it's not actually needed to upgrade Solr versions... Best, Jason [1] https://solr.apache.org/guide/solr/latest/deployment-guide/indexupgrader-tool.html - To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
Re: [PATCH] c-family: Introduce the -Winvalid-noreturn flag from clang with extra tuneability
On 6/1/24 11:31, Julian Waters wrote: Hi Jason, Thanks for the reply! I'll address your comments soon. I have a question, if there is an option defined in c.opt as an Enum, like fstrong-eval-order, and the -no variant of the option is passed, would the Var somehow reflect the negated option? Eg Winvalid-noreturn= C ObjC C++ ObjC++ Var(warn_invalid_noreturn) Joined Enum(invalid_noreturn) Warning Enum Name(invalid_noreturn) Type(int) EnumValue Enum(invalid_noreturn) String(explicit) Value(0) -fstrong-eval-order has fstrong-eval-order C++ ObjC++ Common Alias(fstrong-eval-order=, all, none) to represent that plain -fstrong-eval-order is equivalent to -fstrong-eval-order=all, and -fno-strong-eval-order is equivalent to =none. Would warn_invalid_noreturn then != 0 if -Wno-invalid-noreturn=explicit is passed? Or is there a way to make a warning call depend on 2 different OPT_ entries? Typically = options will specify RejectNegative so the driver will reject e.g. -Wno-invalid-noreturn=explicit. Jason best regards, Julian On Sat, Jun 1, 2024 at 4:57 AM Jason Merrill wrote: On 5/29/24 09:58, Julian Waters wrote: Currently, gcc warns about noreturn marked functions that return both explicitly and implicitly, with no way to turn this warning off. clang does have an option for these classes of warnings, -Winvalid-noreturn. However, we can do better. Instead of just having 1 option that switches the warnings for both on and off, we can define an extra layer of granularity, and have a separate options for implicit returns and explicit returns, as in -Winvalid-return=explicit and -Winvalid-noreturn=implicit. This patch adds both to gcc, for compatibility with clang. Thanks! Do note that I am relatively new to gcc's codebase, and as such couldn't figure out how to cleanly define a general -Winvalid-noreturn warning that switch both on and off, for better compatibility with clang. If someone should point out how to do so, I'll happily rewrite my patch. See -fstrong-eval-order for an example of an option that can be used with or without =arg. I also do not have write access to gcc, and will need help pushing this patch once the green light is given Good to know, I can take care of that. best regards, Julian gcc/c-family/ChangeLog: * c.opt: Introduce -Winvalid-noreturn=explicit and -Winvalid-noreturn=implicit gcc/ChangeLog: * tree-cfg.cc (pass_warn_function_return::execute): Use it gcc/c/ChangeLog: * c-typeck.cc (c_finish_return): Use it * gimple-parser.cc (c_finish_gimple_return): Use it gcc/config/mingw/ChangeLog: * mingw32.h (EXTRA_OS_CPP_BUILTINS): Fix semicolons gcc/cp/ChangeLog: * coroutines.cc (finish_co_return_stmt): Use it * typeck.cc (check_return_expr): Use it gcc/doc/ChangeLog: * invoke.texi: Document new options From 4daf884f8bbc1e318ba93121a6fdf4139da80b64 Mon Sep 17 00:00:00 2001 From: TheShermanTanker Date: Wed, 29 May 2024 21:32:08 +0800 Subject: [PATCH] Introduce the -Winvalid-noreturn flag from clang with extra tuneability The rationale and ChangeLog entries should be part of the commit message (and so the git format-patch output). Signed-off-by: TheShermanTanker A DCO sign-off can't use a pseudonym, sorry; please either sign off using your real name or file a copyright assignment for the pseudonym with the FSF. See https://gcc.gnu.org/contribute.html#legal for more detail. --- gcc/c-family/c.opt | 8 gcc/c/c-typeck.cc | 2 +- gcc/c/gimple-parser.cc | 2 +- gcc/config/mingw/mingw32.h | 6 +++--- gcc/cp/coroutines.cc | 2 +- gcc/cp/typeck.cc | 2 +- gcc/doc/invoke.texi| 13 + gcc/tree-cfg.cc| 2 +- 8 files changed, 29 insertions(+), 8 deletions(-) diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt index fb34c3b7031..32a2859fdcc 100644 --- a/gcc/c-family/c.opt +++ b/gcc/c-family/c.opt @@ -886,6 +886,14 @@ Winvalid-constexpr C++ ObjC++ Var(warn_invalid_constexpr) Init(-1) Warning Warn when a function never produces a constant expression. +Winvalid-noreturn=explicit +C ObjC C++ ObjC++ Warning +Warn when a function marked noreturn returns explicitly. + +Winvalid-noreturn=implicit +C ObjC C++ ObjC++ Warning +Warn when a function marked noreturn returns implicitly. + Winvalid-offsetof C++ ObjC++ Var(warn_invalid_offsetof) Init(1) Warning Warn about invalid uses of the \"offsetof\" macro. diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc index ad4c7add562..1941fbc44cb 100644 --- a/gcc/c/c-typeck.cc +++ b/gcc/c/c-typeck.cc @@ -11468,7 +11468,7 @@ c_finish_return (location_t loc, tree retval, tree origtype) location_t xloc = expansion_point_location_if_in_system_header (loc); if (TREE_THIS_VOLATILE (current_function_decl)) -warning_at (xloc, 0, +warning_at (xloc, OPT_Winvalid_noreturn_explicit, "function
Re: [elixir-core:11772] [Proposal] More compiler warnings for impossible pattern matches (map/struct)
I quite like the idea of more compilation-warnings for impossible pattern
matches! However, it does seem like a lot of work will be needed to get
them reliable and performant enough to get there and I don't have any
insight to add there.
But I do want to point out that the "Map matching on struct specific keys"
isn't an impossible match since not all structs are well-formed, e.g. the
"range" function head can be hit like so:
```
iex(1)> defmodule MapVsStruct do
...(1)> def key_match(%{first: _first}), do: "map"
...(1)> def key_match(%Range{}), do: "range"
...(1)> end
{:module, MapVsStruct,
<<70, 79, 82, 49, 0, 0, 5, 188, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0,
209,
0, 0, 0, 20, 18, 69, 108, 105, 120, 105, 114, 46, 77, 97, 112, 86, 115,
83,
116, 114, 117, 99, 116, 8, 95, 95, 105, ...>>, {:key_match, 1}}
iex(2)> MapVsStruct.key_match(%{__struct__: Range})
"range"
```
So given that I'm not sure we'd want a compilation warning for that pattern
match, so perhaps that warning would make more sense in a linter like Credo.
-Jason
On Thu, May 30, 2024 at 3:25 AM Tobias Pfeiffer wrote:
> Hello everyone,
>
> as usual thanks for all your outstanding work on Elixir & everything else.
>
> Courtesy of a reddit discussion [1] I'd like to propose implementing some
> more compiler warnings for matches that are impossible.
>
> ## Background
>
> Elixir is very programmer friendly and issues compiler warnings in many
> cases if something is impossible. So if we match just against `variable` in
> a function head and further down match against a more specific value we get
> a warning.
>
> Similarly if we match against `__struct__` and the actual struct we get a
> warning:
>
> def struct_match(%{__struct__: Range}), do: "__struct__"
> def struct_match(%Range{}), do: "struct"
>
> This one warns as:
>
> warning: this clause cannot match because a previous clause at line 17
> always matches
> │
> 18 │ def struct_match(%Range{}), do: "struct"
> │
> │
> └─ lib/compiler_warnings_impossible_matches.ex:18
>
> This is great! The idea here is to take it further.
>
> ## Proposal
>
> The code examples used here can be found here:
> https://github.com/PragTob/elixir_playground/blob/main/lib/compiler_warnings_impossible_matches.ex
>
> I tried the examples on 1.18.0-dev (ed67d6b) with OTP 27.0 to make sure
> none of them emit a warning right now.
>
> In short, it's more warnings where for some of which I thought they'd
> already warn you about impossible matches but found out they don't. I think
> these warnings would be helpful to avoid bugs & help newcomers.
>
> ### Simple map match vs. Struct
>
> def map_match(%{}), do: "map"
> def map_match(%Range{}), do: "range"
>
> Ideally this should warn as the match is impossible. Possibly also when
> using the `is_map` guard.
>
> ### Map matching on struct specific keys
>
> def key_match(%{first: _first}), do: "map"
> def key_match(%Range{}), do: "range"
>
> If we had a map where all keys overlap with a struct matched further down
> in the function headers, ideally this should also warn. Of course, if we
> add a second key to the match that the struct doesn't have it should not
> warn.
>
> Of this proposal, I think this is the one that I see causing bugs most
> easily.
>
> ### atoms, nil and booleans
>
> def atom_match(value) when is_atom(value), do: "atom"
> def atom_match(nil), do: "nil"
> def atom_match(value) when is_boolean(value), do: "bool"
>
> I'm not sure how much guards should be taken into account with these kinds
> of warnings, but these are also "unmatchable".
>
> ## Implementation
> I'm aware there is a chance you're aware of this and it wasn't implemented
> for compilation performance considerations. If so, sorry and happy to learn
> how I could look something like this up.
>
> If you agree that this could be worthwhile to implement, I'd be happy to
> give the implementation a shot myself but I'd at least need basic guidance
> as I don't know the internals all that well :)
>
> Thanks y'all and have a splendid day!
>
> [1] https://www.reddit.com/r/elixir/comments/1cibtia/comment/l2ckqjr/
>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-l
Re: [PATCH v7 4/9] C++: Support clang compatible [[musttail]] (PR83324)
On 6/3/24 11:44, Jakub Jelinek wrote:
On Mon, Jun 03, 2024 at 08:33:52AM -0700, Andi Kleen wrote:
On Mon, Jun 03, 2024 at 10:42:20AM -0400, Jason Merrill wrote:
@@ -30316,7 +30348,7 @@ cp_parser_std_attribute (cp_parser *parser, tree
attr_ns)
/* Maybe we don't expect to see any arguments for this attribute. */
const attribute_spec *as
= lookup_attribute_spec (TREE_PURPOSE (attribute));
-if (as && as->max_length == 0)
+if ((as && as->max_length == 0) || is_attribute_p ("musttail", attr_id))
This shouldn't be necessary with the attribute in the c-attribs table,
right? This patch is OK without this hunk and with the comment tweak above.
Yes I will remove it. Also the hunk above can be simplified, we don't
need the extra case anymore.
But unfortunately there's another problem (sorry I missed that earlier
but the Linaro bot pointed it out again):
This hunk:
@@ -21085,12 +21085,14 @@ tsubst_expr (tree t, tree args, tsubst_flags_t
complain, tree in_decl)
bool op = CALL_EXPR_OPERATOR_SYNTAX (t);
bool ord = CALL_EXPR_ORDERED_ARGS (t);
bool rev = CALL_EXPR_REVERSE_ARGS (t);
- if (op || ord || rev)
+ bool mtc = CALL_EXPR_MUST_TAIL_CALL (t);
+ if (op || ord || rev || mtc)
if (tree call = extract_call_expr (ret))
{
CALL_EXPR_OPERATOR_SYNTAX (call) = op;
CALL_EXPR_ORDERED_ARGS (call) = ord;
CALL_EXPR_REVERSE_ARGS (call) = rev;
+ CALL_EXPR_MUST_TAIL_CALL (call) = mtc;
}
The difference is that CALL_EXPR_MUST_TAIL_CALL is defined as:
#define CALL_EXPR_MUST_TAIL_CALL(NODE) \
(CALL_EXPR_CHECK (NODE)->base.static_flag)
while the others like:
#define CALL_EXPR_ORDERED_ARGS(NODE) \
TREE_LANG_FLAG_3 (CALL_OR_AGGR_INIT_CHECK (NODE))
where
#define CALL_OR_AGGR_INIT_CHECK(NODE) \
TREE_CHECK2 ((NODE), CALL_EXPR, AGGR_INIT_EXPR)
while
#define CALL_EXPR_CHECK(t) TREE_CHECK (t, CALL_EXPR)
(this one is defined in generated tree-check.h).
So, while the CALL_EXPR_REVERSE_ARGS etc. can be used on either
CALL_EXPR or AGGR_INIT_EXPR (the latter is a C++ specific tree code),
CALL_EXPR_MUST_TAIL_CALL is allowed only on CALL_EXPR.
AGGR_INIT_EXPR is used for C++ constructor calls, so I think
they really don't need such a flag
AGGR_INIT_EXPR is also used for functions returning a class, so I think
it is needed.
Jason
[jira] [Comment Edited] (IMPALA-12981) Support a column list in compute stats that is retrieved via a subquery
[
https://issues.apache.org/jira/browse/IMPALA-12981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851719#comment-17851719
]
Jason Fehr edited comment on IMPALA-12981 at 6/3/24 4:24 PM:
-
Use Case -- customers can run compute stats on the weekends for the most
popular columns on the most popular tables. This use case must be accomplished
using only sql without using a scripting language.
was (Author: JIRAUSER298428):
Use Case -- customers can run compute stats on the weekends for the most
popular columns on the most popular tables.
> Support a column list in compute stats that is retrieved via a subquery
> -
>
> Key: IMPALA-12981
> URL: https://issues.apache.org/jira/browse/IMPALA-12981
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend, Frontend
>Reporter: Manish Maheshwari
>Priority: Major
>
> Support a column list in compute stats that is retrived via a subquery -
> Specifically we want to use Impala query history tables where we collect the
> columns in a table that are using for joins, aggegrates, filters etc to be
> passed into compute stats command -
> Suggested Syntax -
> {code:java}
> compute stats db.tbl (
> select distinct join_columns from
> from sys.impala_query_log
> where contains(tables_queried, "db.tbl")
> and query_dttm >current_timestamp()-7
> and join_columns rlike 'db.tbl'
> ) {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-12981) Support a column list in compute stats that is retrieved via a subquery
[
https://issues.apache.org/jira/browse/IMPALA-12981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851719#comment-17851719
]
Jason Fehr commented on IMPALA-12981:
-
Use Case -- customers can run compute stats on the weekends for the most
popular columns on the most popular tables.
> Support a column list in compute stats that is retrieved via a subquery
> -
>
> Key: IMPALA-12981
> URL: https://issues.apache.org/jira/browse/IMPALA-12981
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend, Frontend
>Reporter: Manish Maheshwari
>Priority: Major
>
> Support a column list in compute stats that is retrived via a subquery -
> Specifically we want to use Impala query history tables where we collect the
> columns in a table that are using for joins, aggegrates, filters etc to be
> passed into compute stats command -
> Suggested Syntax -
> {code:java}
> compute stats db.tbl (
> select distinct join_columns from
> from sys.impala_query_log
> where contains(tables_queried, "db.tbl")
> and query_dttm >current_timestamp()-7
> and join_columns rlike 'db.tbl'
> ) {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-12648) Support killing queries and sessions programatically
[
https://issues.apache.org/jira/browse/IMPALA-12648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851714#comment-17851714
]
Jason Fehr commented on IMPALA-12648:
-
security requirement -- kill() function is only allowed for admin users or the
user who owns the query/session.
> Support killing queries and sessions programatically
>
>
> Key: IMPALA-12648
> URL: https://issues.apache.org/jira/browse/IMPALA-12648
> Project: IMPALA
> Issue Type: New Feature
> Components: Frontend
>Affects Versions: Impala 4.3.0
>Reporter: Manish Maheshwari
>Assignee: Jason Fehr
>Priority: Major
>
> Support killing queries and sessions programatically via kill commands to be
> able to manage impala running workloads.
> 1. Killing Queries that are currently running
> {code:java}
> -- Forcibly terminates query with the specified query_id:
> KILL QUERY WHERE query_id='634bf9fcf55278eb:ac0ef053' {code}
> For queries that are the finished and waiting to be closed, this command
> should close them
> 2. Killing sessions that are open
> {code:java}
> -- Forcibly terminates session and closes all queries:
> KILL SESSION WHERE session_id='2644d52c79c4c1e4:e974538f2189ed82' {code}
> this command should terminate the session and kill all active queries and
> close all queries that are finished and are waiting to be closed.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
Re: [PATCH v2 2/2] C++: Support constexpr strings for asm statements
On 6/2/24 23:45, Andi Kleen wrote:
Some programing styles use a lot of inline assembler, and it is common
to use very complex preprocessor macros to generate the assembler
strings for the asm statements. In C++ there would be a typesafe alternative
using templates and constexpr to generate the assembler strings, but
unfortunately the asm statement requires plain string literals, so this
doesn't work.
This patch modifies the C++ parser to accept strings generated by
constexpr instead of just plain strings. This requires new syntax
because e.g. asm("..." : "r" (expr)) would be ambigious with a function
call. I chose () to make it unique. For example now you can write
constexpr const char *genasm() { return "insn"; }
constexpr const char *genconstraint() { return "r"; }
asm(genasm() :: (genconstraint()) (input));
Looks plausible. What happens when someone forgets the parens, as seems
a likely mistake?
The constexpr strings are allowed for the asm template, the
constraints and the clobbers (every time current asm accepts a string)
This version allows the same constexprs as C++26 static_assert,
following Jakub's suggestion.
The drawback of this scheme is that the constexpr doesn't have
full control over the input/output/clobber lists, but that can be
usually handled with a switch statement. One could imagine
more flexible ways to handle that, for example supporting constexpr
vectors for the clobber list, or similar. But even without
that it is already useful.
Bootstrapped and full test on x86_64-linux.
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Define
__GNU_CONSTEXPR_ASM__.
__GXX instead of __GNU would be more consistent with the other old
predefined macros.
Jason
Re: [PATCH v7 6/9] Add tests for C/C++ musttail attributes
tions "-std=gnu++11" { target c++ } } */
+
+[[musttail]] int j; /* { dg-warning "attribute" } */
+__attribute__((musttail)) int k; /* { dg-warning "attribute" } */
+
+void foo(void)
+{
+ [[gnu::musttail]] j++; /* { dg-warning "attribute" } */
+ [[gnu::musttail]] if (k > 0) /* { dg-warning "attribute" } */
+[[gnu::musttail]] k++; /* { dg-warning "attribute" } */
+}
+
+int foo2(int p)
+{
+ [[gnu::musttail(1)]] return foo2(p + 1); /* { dg-error "\(before numeric
constant|attribute\)" } */
+}
+
+int i;
+
+int foo3(void)
+{
+ [[musttail]] i++; /* { dg-warning "attribute" } */
+ [[musttail]] if (i > 10) /* { dg-warning "attribute" } */
+[[musttail]] return foo2(i); /* { dg-warning "attribute" } */
+ return 0;
+}
diff --git a/gcc/testsuite/c-c++-common/musttail7.c
b/gcc/testsuite/c-c++-common/musttail7.c
new file mode 100644
index ..5e4eb1bfbacc
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/musttail7.c
@@ -0,0 +1,14 @@
+/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
+/* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
+
+extern void f();
+
+void f2()
+{
+ [[gnu::musttail]] return f2();
+}
+
+void f3()
+{
+ [[gnu::musttail]] return f();
+}
diff --git a/gcc/testsuite/c-c++-common/musttail8.c
b/gcc/testsuite/c-c++-common/musttail8.c
new file mode 100644
index ..9fa10e0b54c4
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/musttail8.c
@@ -0,0 +1,17 @@
+/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
+
+float f1(void);
+
+int f2(void)
+{
+ [[gnu::musttail]] return f1 (); /* { dg-error "changed after call" } */
+}
+
+
+int f3(int *);
+
+int f4(void)
+{
+ int x;
+ [[gnu::musttail]] return f3(); /* { dg-error "\(refers to locals|other
reasons\)" } */
+}
diff --git a/gcc/testsuite/g++.dg/musttail10.C
b/gcc/testsuite/g++.dg/musttail10.C
new file mode 100644
index ..6da7e021f826
--- /dev/null
+++ b/gcc/testsuite/g++.dg/musttail10.C
@@ -0,0 +1,20 @@
+/* { dg-do compile { target { tail_call } } } */
+/* { dg-options "-std=gnu++11" } */
+/* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
+
+int f();
+
+double h() { [[gnu::musttail]] return f(); } /* { dg-error "cannot tail-call"
} */
+
+/* The error check cannot distinguish between the (valid) int and the invalid
+ double conversion case because the template context is lost when
tree-tailcall
+ finally runs. */
Maybe use identical g1 and g2 to distinguish?
+
+template
+T g() { [[gnu::musttail]] return f(); } /* { dg-error "cannot tail-call" } */
+
+int main()
+{
+ g();
+ g();
+}
diff --git a/gcc/testsuite/g++.dg/musttail6.C b/gcc/testsuite/g++.dg/musttail6.C
new file mode 100644
index ..e0e478e08d58
--- /dev/null
+++ b/gcc/testsuite/g++.dg/musttail6.C
@@ -0,0 +1,58 @@
+/* { dg-do compile { target { tail_call } } } */
+/* { dg-options "-std=gnu++11" } */
+/* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
+
+class Foo {
+public:
+ int a, b;
+ Foo(int a, int b) : a(a), b(b) {}
+};
+
+Foo __attribute__((noinline,noclone,noipa))
+callee (int i)
+{
+ return Foo(i, i+1);
+}
+
+Foo __attribute__((noinline,noclone,noipa))
+caller (int i)
+{
+ [[gnu::musttail]] return callee (i + 1);
+}
+
+template
+T __attribute__((noinline,noclone,noipa)) foo (T i)
+{
+ return i + 1;
+}
+
+int
+caller2 (int k)
+{
+ [[gnu::musttail]] return foo(1);
+}
+
+template
+T caller3 (T v)
+{
+ [[gnu::musttail]] return foo(v);
+}
+
+int call3(int i)
+{
+ [[gnu::musttail]] return caller3(i + 1);
+}
+
+struct Bar {
+ int a;
+ Bar(int a) : a(a) {}
+ Bar operator+(Bar o) { return Bar(a + o.a); }
+};
+
+#if __OPTIMIZE__ >= 1
+Bar
+caller4 (Bar k)
+{
+ [[gnu::musttail]] return caller3(Bar(99));
+}
+#endif
diff --git a/gcc/testsuite/g++.dg/musttail9.C b/gcc/testsuite/g++.dg/musttail9.C
new file mode 100644
index ..8095bdf6fe62
--- /dev/null
+++ b/gcc/testsuite/g++.dg/musttail9.C
@@ -0,0 +1,10 @@
+/* { dg-do compile { target { tail_call } } } */
+/* { dg-options "-std=gnu++11 -Wno-deprecated" } */
+/* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
+
+extern void foo() throw(const char *);
+
+void f() throw()
+{
+ [[gnu::musttail]] return foo(); /* { dg-error "call may throw exception that does
not propagate" } */
+}
Instead of -Wno-deprecated let's use C++11 exception-specifications; you
can leave out the exception specification on foo and change f's to
"noexcept".
Jason
Re: [PATCH v7 4/9] C++: Support clang compatible [[musttail]] (PR83324)
first, since type
deduction is not valid there. */
if (keyword == RID_CO_RETURN)
@@ -30316,7 +30348,7 @@ cp_parser_std_attribute (cp_parser *parser, tree
attr_ns)
/* Maybe we don't expect to see any arguments for this attribute. */
const attribute_spec *as
= lookup_attribute_spec (TREE_PURPOSE (attribute));
-if (as && as->max_length == 0)
+if ((as && as->max_length == 0) || is_attribute_p ("musttail", attr_id))
This shouldn't be necessary with the attribute in the c-attribs table,
right? This patch is OK without this hunk and with the comment tweak above.
Jason
Re: [PATCH v2 1/2] Factor out static_assert constexpr string extraction for reuse
On 6/2/24 23:45, Andi Kleen wrote:
No intentional semantics change.
gcc/cp/ChangeLog:
* cp-tree.h (struct cstr): Add structure.
(get_cstr): Declare.
(extract_cstr): Declare.
(free_cstr): Declare.
* semantics.cc (finish_static_assert): Factor out constant
string expression extraction code and move to...
(get_cstr): Here.
(extract_cstr): Dito.
(free_cstr): Dito.
---
gcc/cp/cp-tree.h| 17 +++
gcc/cp/semantics.cc | 292 +---
2 files changed, 184 insertions(+), 125 deletions(-)
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 565e4a9290e2..25b8033db788 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -9015,6 +9015,23 @@ struct push_access_scope_guard
}
};
+/* Extracting strings from constexpr */
+
+/* Temporary data for extracting constant string. */
+struct cstr
+{
+ tree message;
+ tree message_data;
+ tree message_sz;
+ char *buf;
+};
+
+bool get_cstr (tree message, location_t location, const char *what, const char
*what2,
+ cstr );
+bool extract_cstr (const char *what, const char *what2, location_t location,
+ cstr , const char * & msg, int );
+void free_cstr (cstr );
get_ and extract_ are confusingly similar names. Let's make cstr more
of a class, initialized at least from 'message', and perhaps from the
other context information.
Then get_ can be something like cstr::type_check. And then free_cstr is
the destructor, and the copy constructor is deleted.
And please don't use the same name for the class and parameter/variables
of that type.
+ error_at (location, "%qs %s must be a string "
From ABOUT-GCC-NLS: "Avoid using %s to compose a diagnostic message
from multiple translatable strings; instead, write out the full
diagnostic message for each variant. Only use %s for message components
that do not need translation, such as keywords."
Also, if you are passing an English string for a diagnostic to a
function that isn't from diagnostic.h, you need to use the intl.h macros
to mark it for translation.
Jason
