On Thu, Oct 17, 2024 at 4:53 PM Srujana Challa wrote:
>
> > Subject: Re: [EXTERNAL] Re: [PATCH v2 0/2] vhost-vdpa: Add support for NO-
> > IOMMU mode
> >
> > On Wed, Oct 16, 2024 at 05:28:27PM +, Srujana Challa wrote:
> > > When using the DPDK virtio user PMD, we’ve noticed a significant 70%
>
On Fri, Oct 18, 2024 at 10:48 AM Zhang, Chen wrote:
>
> Add Trivial patches Maintainers.
>
>
>
> Hi Jason/Michael/Laurent,
>
> Can you help to pick up this patch for upstream and stable?
Queued.
Btw, if you want -stable next time, please cc it.
Thanks
>
>
&g
On Thu, Oct 17, 2024 at 5:42 PM Akihiko Odaki wrote:
>
> On 2024/10/17 18:17, Laurent Vivier wrote:
> > On 17/10/2024 11:07, Akihiko Odaki wrote:
> >> On 2024/10/17 16:32, Laurent Vivier wrote:
> >>> On 17/10/2024 08:59, Jason Wang wrote:
> >>>>
On Thu, Oct 17, 2024 at 3:58 PM Duan, Zhenzhong
wrote:
>
>
>
> >-Original Message-
> >From: Jason Wang
> >Subject: Re: [PATCH v2] intel_iommu: Introduce property "x-stale-tm" to
> >control
> >Transient Mapping (TM) field
> >
>
Author: Jason Molenda
Date: 2024-10-17T19:46:08-07:00
New Revision: 9c6f85f57a74278e4833f3da2606d80e7577d6d5
URL:
https://github.com/llvm/llvm-project/commit/9c6f85f57a74278e4833f3da2606d80e7577d6d5
DIFF:
https://github.com/llvm/llvm-project/commit/9c6f85f57a74278e4833f3da2606d80e7577d6d5.diff
ges_to_xen((unsigned long)maddr_to_virt(bi->mods[i].start),
+maddr_to_mfn(bi->mods[i].start),
+PFN_UP(bi->mods[i].size), PAGE_HYPERVISOR);
I would vertically align all the parameters inside the (.
}
#ifdef CONFIG_KEXEC
With those:
Reviewed-by: Jason Andryuk
Regards,
Jason
jasonmolenda wrote:
FTR I have an intel mac running the same OS as the CI bots (`LLVM host triple:
x86_64-apple-darwin22.6.0` it's macOS 13.5 aka macOS Ventura from 2022), and am
building github main so I can try to repo this failure and Alex's on this shell
test. I don't really think I'm goi
end - _stext;
+bi->mods[xen].start = virt_to_maddr(_stext);
+bi->mods[xen].size = __2M_rwdata_end - _stext;
+
+bi->mods[xen].mod->mod_start = bi->mods[xen].start;
But now this line needs to be converted to an mfn?
Regards,
Jason
+bi->mods[xen].mod
addresses.
converted
Signed-off-by: Daniel P. Smith
with that
Reviewed-by: Jason Andryuk
EFI now gains the alignment check, but beforehand it was just silently
truncating. Seems better to check :)
Regards,
Jason
, such as domain construction.
Signed-off-by: Daniel P. Smith
Reviewed-by: Jason Andryuk
nt?
+map_pages_to_xen((unsigned
long)mfn_to_virt(bi->mods[i].mod->mod_start),
+_mfn(bi->mods[i].mod->mod_start),
+ PFN_UP(bi->mods[i].mod->mod_end), PAGE_HYPERVISOR);
}
#ifdef CONFIG_KEXEC
Regards,
Jason
around. It also lays the groundwork for hyperlaunch mult-domain
construction, where multiple instances of state variables like headroom will be
needed.
Signed-off-by: Daniel P. Smith
Reviewed-by: Jason Andryuk
On 2024-10-17 13:02, Daniel P. Smith wrote:
Transition the incoming boot loader name to be held in struct boot_info.
No functional change intended.
Signed-off-by: Daniel P. Smith
Reviewed-by: Jason Andryuk
Jason Fehr has posted comments on this change. (
http://gerrit.cloudera.org:8080/21929 )
Change subject: BLOG: Add blog post for Impala talks at Community Over Code NA
2024
..
Patch Set 5: Code-Review+1
--
To view, visit
On Thu, Oct 17, 2024 at 03:11:10PM -0400, Peter Xu wrote:
> On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
> > > If so, maybe that's a non-issue for non-CoCo, where the VM object /
> > > gmemfd object (when created) can have a flag marking that it
t thread series together like this with reply-to, it breaks b4 and
other tools ability to tell them apart.. Just post them separately
normally.
Jason
i/iommufd.rst | 66 -
> 1 file changed, 65 insertions(+), 1 deletion(-)
Reviewed-by: Jason Gunthorpe
Jason
i/iommufd.rst | 58 ++---
> 1 file changed, 42 insertions(+), 16 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
pi.c | 7 +++
> 2 files changed, 14 insertions(+)
Reviewed-by: Jason Gunthorpe
Jason
d selftest case accordingly.
>
> Reviewed-by: Jason Gunthorpe
> Signed-off-by: Nicolin Chen
> ---
> include/uapi/linux/iommufd.h| 9 ---
> drivers/iommu/iommufd/hw_pagetable.c| 32 +++--
> tools/testing/selftests/iommu/iommufd.c | 4 ++--
&g
Jason Fehr has posted comments on this change. (
http://gerrit.cloudera.org:8080/21929 )
Change subject: Add blog post for Impala talks at Community Over Code NA 2024
..
Patch Set 2:
(4 comments)
http://gerrit.cloudera.org
gt; drivers/iommu/iommufd/hw_pagetable.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
Reviewed-by: Jason Gunthorpe
Jason
On Thu, Oct 17, 2024 at 11:50:44AM -0700, Nicolin Chen wrote:
> On Thu, Oct 17, 2024 at 03:47:29PM -0300, Jason Gunthorpe wrote:
> > On Wed, Oct 09, 2024 at 09:38:14AM -0700, Nicolin Chen wrote:
> > > An IOMMU_VIOMMU_TYPE_DEFAULT doesn't need a free() op since the core can
&
->out_vdevice_id = vdev->obj.id;
> + rc = iommufd_ucmd_respond(ucmd, sizeof(*cmd));
> + if (rc)
> + goto out_abort;
> + iommufd_object_finalize(ucmd->ictx, &vdev->obj);
> + goto out_unlock_igroup;
> +
> +out_abort:
> + iommufd_object_abort_and_destroy(ucmd->ictx, &vdev->obj);
But be mindful of this abort, it doesn't want to be inside the lock if
it also gets the lock.. fail_nth should be updated to cover these new
ioctls to look for tricky things like that
But the design looks OK
Jason
mu_ops for driver to hook ops for default vIOMMUs.
Why? arm_smmu is now creating its own viommu object, so who will use
this?
Do we have any use for the default mode? It is already a bit
confusing, can we just drop it?
Jason
object_alloc_elm(ictx, size, IOMMUFD_OBJ_VDEVICE);
> + if (IS_ERR(obj))
> + return ERR_CAST(obj);
> + return container_of(obj, struct iommufd_vdevice, obj);
> +}
Like for the viommu this can all just be folded into the #define
Jason
+
> + if (viommu_type != IOMMU_VIOMMU_TYPE_ARM_SMMUV3)
> + return ERR_PTR(-EOPNOTSUPP);
So what happens if the user tries to create a default domain?
It skips this and just creates an normal viommu object
But then what? The driver needs to make sure it never casts that to a
arm_vsmmu ? How?
Jason
> Laurent Rineau writes:
> The result is that the following
> packages no longer build (F42FTBFS, RAWHIDEFTBFS):
> - prusa-slicer
> https://koji.fedoraproject.org/koji/taskinfo?taskID=124921682
Just so I don't forget (as I have no time to dig into this today), I see
some related information
On Thu, Oct 17, 2024 at 10:21:31AM -0700, Nicolin Chen wrote:
> On Thu, Oct 17, 2024 at 01:51:51PM -0300, Jason Gunthorpe wrote:
> > On Wed, Oct 09, 2024 at 09:38:05AM -0700, Nicolin Chen wrote:
> > > With a viommu object wrapping a potentially shareable S2 domain, a nested
>
7;s iommu ops match the viommu's iommu ops (or is null for
default) before allowing the callback.
Jason
On Thu, Oct 17, 2024 at 07:11:46PM +0200, David Hildenbrand wrote:
> On 17.10.24 18:47, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> >
> > > My question was more torwards whether gmemfd could still expose the
> > > poss
>users)) {
It would be a bug if the iommu_dev being passed in was somehow
released while iommufd had hold of it through vfio. So just use
refcount_inc()
Jason
queue_head_t wait;
Just use a completion instead of a wait_queue, a few more bytes but it
is easier to code. This has some subtle issue where the device memory
could be freed while a concurrent thread is going to trigger the wait.
Jason
const struct iommu_user_data *user_data)
>
> {
Do these all need to check for NULL viommu now too? Something is
needed at least, only valid viommus should be accepted here. Like you
can't pass an ARM viommu to AMD or something silly.
Should drivers accept the default viommu?
Jason
On Thu, Oct 17, 2024 at 01:05:34PM -0400, Peter Xu wrote:
> On Thu, Oct 17, 2024 at 01:47:13PM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> >
> > > My question was more torwards whether gmemfd could still expose the
> &g
On Thu, Oct 17, 2024 at 10:01:28AM -0700, Nicolin Chen wrote:
> On Thu, Oct 17, 2024 at 01:33:59PM -0300, Jason Gunthorpe wrote:
>
> > > diff --git a/drivers/iommu/iommufd/viommu_api.c
> > > b/drivers/iommu/iommufd/viommu_api.c
> > > new file mode 100644
>
On Thu, Oct 17, 2024 at 09:48:23AM -0700, Nicolin Chen wrote:
> On Thu, Oct 17, 2024 at 01:35:07PM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 09:12:03AM -0700, Nicolin Chen wrote:
> >
> > > > Then you can keep the pattern of _ being the allocation fu
pages.
And you definitely can't get the private pages out of the VA interface
because all the VMA PTEs of private pages are non-present by definition.
Hence, you must use the FD for a lot of use cases here.
Jason
On Thu, Oct 17, 2024 at 09:43:22AM -0700, Nicolin Chen wrote:
> On Thu, Oct 17, 2024 at 01:41:23PM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 09:28:16AM -0700, Nicolin Chen wrote:
> > > On Wed, Oct 09, 2024 at 09:38:11AM -0700, Nicolin Chen wrote:
> > >
ng changes to this commit (will be in v4).
> It replaces nested_domain->s2_parent with nested_domain->vsmmu
Err, do we want to make a viommu a hard requirement to use nesting? Is
that what is happening here?
Jason
anged, 142 insertions(+), 1 deletion(-)
> create mode 100644 drivers/iommu/iommufd/viommu.c
Reviewed-by: Jason Gunthorpe
Jason
e pattern
Maymbe "member" is a better word here than elm
Jason
etof(struct drv_struct, member.obj) == 0); \
ret = (struct drv_struct *)iommufd_object_alloc_elm( \
ictx, sizeof(struct drv_struct), IOMMUFD_OBJ_VIOMMU); \
ret->member.ops = viommu_ops; \
ret; \
})
Jason
On Thu, Oct 17, 2024 at 11:14:16AM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 09, 2024 at 09:38:02AM -0700, Nicolin Chen wrote:
>
> > @@ -217,12 +217,12 @@ iommufd_object_put_and_try_destroy(struct iommufd_ctx
> > *ictx,
> > iommufd_object_remo
approachable for some folks!
But no worries if not.)
Thanks for raising this!
Best,
Jason
On Thu, Oct 17, 2024 at 7:45 AM Sebastian Hofmann
wrote:
>
> Hello,
>
> I am currently setting up a Solr cluster using version 9.7. Everything is
> working quite well, except for one issue.
size_t size,
> + enum iommufd_object_type type);
Maybe call it raw instead of elm? elm suggests it is an item in an
array or likewise
Naming aside
Reviewed-by: Jason Gunthorpe
Jason
On Thu, Oct 17, 2024 at 06:49:30AM -0700, Christoph Hellwig wrote:
> On Thu, Oct 17, 2024 at 10:46:44AM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 06:12:55AM -0700, Christoph Hellwig wrote:
> > > On Thu, Oct 17, 2024 at 10:05:39AM -0300, Jason Gunthorpe wrote:
On Thu, Oct 17, 2024 at 06:49:30AM -0700, Christoph Hellwig wrote:
> On Thu, Oct 17, 2024 at 10:46:44AM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 06:12:55AM -0700, Christoph Hellwig wrote:
> > > On Thu, Oct 17, 2024 at 10:05:39AM -0300, Jason Gunthorpe wrote:
[
https://issues.apache.org/jira/browse/SOLR-16825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890457#comment-17890457
]
Jason Gerlowski commented on SOLR-16825:
This ticket added our 'ap
[
https://issues.apache.org/jira/browse/SOLR-15750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890453#comment-17890453
]
Jason Gerlowski commented on SOLR-15750:
Yep, AddReplicaProperty (and
On Thu, Oct 17, 2024 at 06:12:55AM -0700, Christoph Hellwig wrote:
> On Thu, Oct 17, 2024 at 10:05:39AM -0300, Jason Gunthorpe wrote:
> > Broadly I think whatever flow NVMe uses for P2P will apply to ODP as
> > well.
>
> ODP is a lot simpler than NVMe for P2P actually :(
On Thu, Oct 17, 2024 at 06:12:55AM -0700, Christoph Hellwig wrote:
> On Thu, Oct 17, 2024 at 10:05:39AM -0300, Jason Gunthorpe wrote:
> > Broadly I think whatever flow NVMe uses for P2P will apply to ODP as
> > well.
>
> ODP is a lot simpler than NVMe for P2P actually :(
[
https://issues.apache.org/jira/browse/SOLR-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890452#comment-17890452
]
Jason Gerlowski commented on SOLR-6122:
---
I agree with David - the thor
he limitation.
I see, so that is more complicated.
Lu, what do you think about also checking if the PCI function has PRI
? If not PRI assume the fault is special and doesn't follow PRI rules?
Or maybe we can have the iommu driver tag the event as a PRI/not-PRI
fault?
Jason
On Thu, Oct 17, 2024 at 04:58:12AM -0700, Christoph Hellwig wrote:
> On Wed, Oct 16, 2024 at 02:44:45PM -0300, Jason Gunthorpe wrote:
> > > > FWIW, I've been expecting this series to be rebased on top of Leon's
> > > > new DMA API series so it doesn't
On Thu, Oct 17, 2024 at 04:58:12AM -0700, Christoph Hellwig wrote:
> On Wed, Oct 16, 2024 at 02:44:45PM -0300, Jason Gunthorpe wrote:
> > > > FWIW, I've been expecting this series to be rebased on top of Leon's
> > > > new DMA API series so it doesn't
On 10/15/24 2:05 PM, Patrick Palka wrote:
This was added as part of the initial Concepts TS implementation and
reflects an early version of the Concepts TS paper, which is very
different from standard C++20 concepts (and even from more recent
versions of the Concepts TS, support for which we depr
On Thu, Oct 17, 2024 at 09:44:18AM +0800, Zhangfei Gao wrote:
> On Wed, 16 Oct 2024 at 23:25, Jason Gunthorpe wrote:
> >
> > On Wed, Oct 16, 2024 at 09:58:36AM +0800, Zhangfei Gao wrote:
> > > On Tue, 15 Oct 2024 at 20:54, Jason Gunthorpe wrote:
> > > >
> &
not there yet..
> > We don't need to enforce, it we don't know what else the driver will
> > want to use that P2P page for after all. It might stick it in a VMA
> > for some unrelated reason.
>
> And wouldn't that touch the refcount and therefore be wrong?
I mean the originating driver would do that
Jason
not there yet..
> > We don't need to enforce, it we don't know what else the driver will
> > want to use that P2P page for after all. It might stick it in a VMA
> > for some unrelated reason.
>
> And wouldn't that touch the refcount and therefore be wrong?
I mean the originating driver would do that
Jason
On Thu, Oct 10, 2024 at 3:57 PM Zhenzhong Duan wrote:
>
> VT-d spec removed Transient Mapping (TM) field from second-level page-tables
> and treat the field as Reserved(0) since revision 3.2.
>
> Changing the field as reserved(0) will break backward compatibility, so
> introduce a property "x-stal
> Fixes: 5a2414bc454e ("virtio: Intel IFC VF driver for VDPA")
> Signed-off-by: Yuan Can
Acked-by: Jason Wang
Thanks
On Mon, Oct 14, 2024 at 11:16 PM Laurent Vivier wrote:
>
> On 14/10/2024 10:30, Laurent Vivier wrote:
> > Hi Akihiko,
> >
> > On 04/06/2024 09:37, Jason Wang wrote:
> >> From: Akihiko Odaki
> >>
> >> Multiqueue usage is not negotiated yet when
On Tue, Oct 15, 2024 at 6:19 PM Michael S. Tsirkin wrote:
>
> On Mon, Oct 14, 2024 at 03:56:33PM -0500, Mike Christie wrote:
> > On 10/3/24 8:58 PM, Cindy Lu wrote:
> > > Add a new UAPI to support setting the vhost device to
> > > use task mode. The user space application needs to use
> > > VHOST_
Hi Michael:
On Wed, Oct 16, 2024 at 1:58 AM Michael Tokarev wrote:
>
> On 15.09.2024 04:06, Akihiko Odaki wrote:
> > Most of this series are fixes for software RSS and hash reporting, which
> > should have no production user.
> >
> > However there is one exception; patch "virtio-net: Fix size che
enough to make bitmap an array of u64.
>
> Fixes: 941168f8b40e5 ("virtio_net: support device stats")
> Reported-by: "Colin King (gmail)"
> Signed-off-by: Michael S. Tsirkin
> ---
Acked-by: Jason Wang
Thanks
jasonmolenda wrote:
(wrote that update too quickly while running out the door -- I can run the
lldb-shell tests both with and without your patch, and they pass. I'm not able
to repo the failure the CI bots saw.)
https://github.com/llvm/llvm-project/pull/111409
jasonmolenda wrote:
I was able to build github main on an Intel mac running the current OS, and the
shell tests all pass with it. I had the same difficulty trying to repo a
failure with this test with Alex's change, I could never get the failure the CI
bots were hitting, but I didn't have the
https://github.com/jasonmolenda approved this pull request.
https://github.com/llvm/llvm-project/pull/112639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
On Wed, Oct 16, 2024 at 07:49:31PM -0400, Peter Xu wrote:
> On Wed, Oct 16, 2024 at 07:51:57PM -0300, Jason Gunthorpe wrote:
> > On Wed, Oct 16, 2024 at 04:16:17PM -0400, Peter Xu wrote:
> > >
> > > Is there chance that when !CoCo will be supported, then external mo
with iommufd was to see fd + offest as the "new" way
to refer to all guest memory and discourage people from using VMA
handles.
Jason
Jason Fehr has posted comments on this change. (
http://gerrit.cloudera.org:8080/21864 )
Change subject: IMPALA-13340: Fix missing partitions in COPY TESTCASE of
LocalCatalog mode
..
Patch Set 2:
(5 comments)
http
Jason Fehr has posted comments on this change. (
http://gerrit.cloudera.org:8080/21842 )
Change subject: IMPALA-13395: Adds USE_APACHE_COMPONENTS=true in
all-build-options job
..
Patch Set 1: Code-Review+1
--
To view, visit
Jason Fehr has posted comments on this change. (
http://gerrit.cloudera.org:8080/21930 )
Change subject: IMPALA-12648: Add KILL QUERY statement
..
Patch Set 2:
(16 comments)
Good start!
http://gerrit.cloudera.org:8080/#/c
he system considers an item called "apple" to
exist operationally, would a get-data from "operational" return this?
apple
Jason (he/him)
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
0.04s sshd:
root@pts/1
pts/0 should have been about 15m in this case
Do I need to make a new bug report?
Jason
On Tue, Oct 15, 2024 at 4:31 PM Calvin Cheng <2073...@bugs.launchpad.net>
wrote:
> This has been fixed in the latest release of procps version
> 2:4.0.4-4ubuntu3.2.
>
>
0.04s sshd:
root@pts/1
pts/0 should have been about 15m in this case
Do I need to make a new bug report?
Jason
On Tue, Oct 15, 2024 at 4:31 PM Calvin Cheng <2073...@bugs.launchpad.net>
wrote:
> This has been fixed in the latest release of procps version
> 2:4.0.4-4ubuntu3.2.
>
>
On Wed, Oct 16, 2024 at 09:41:03AM -0700, Christoph Hellwig wrote:
> On Wed, Oct 16, 2024 at 12:44:28PM -0300, Jason Gunthorpe wrote:
> > > We are talking about P2P memory here. How do you manage to get a page
> > > that dma_map_page can be used on? All P2P memory
On Wed, Oct 16, 2024 at 09:41:03AM -0700, Christoph Hellwig wrote:
> On Wed, Oct 16, 2024 at 12:44:28PM -0300, Jason Gunthorpe wrote:
> > > We are talking about P2P memory here. How do you manage to get a page
> > > that dma_map_page can be used on? All P2P memory
hould
> have a zero refcount to enforce that.
I think that is just the rule for hmm stuff in general, don't touch
the refcount.
We don't need to enforce, it we don't know what else the driver will
want to use that P2P page for after all. It might stick it in a VMA
for some unrelated reason.
Jason
hould
> have a zero refcount to enforce that.
I think that is just the rule for hmm stuff in general, don't touch
the refcount.
We don't need to enforce, it we don't know what else the driver will
want to use that P2P page for after all. It might stick it in a VMA
for some unrelated reason.
Jason
system without an
iommu translation?
> which also makes it clear that returning a page from the method is
> not that great, a PFN might work a lot better, e.g.
>
> unsigned long (*device_private_dma_pfn)(struct page *page);
Ideally I think we should not have the struct page * at all through
these APIs if we can avoid it..
Jason
system without an
iommu translation?
> which also makes it clear that returning a page from the method is
> not that great, a PFN might work a lot better, e.g.
>
> unsigned long (*device_private_dma_pfn)(struct page *page);
Ideally I think we should not have the struct page * at all through
these APIs if we can avoid it..
Jason
On Wed, Oct 16, 2024 at 09:58:36AM +0800, Zhangfei Gao wrote:
> On Tue, 15 Oct 2024 at 20:54, Jason Gunthorpe wrote:
> >
> > On Tue, Oct 15, 2024 at 11:19:33AM +0800, Zhangfei Gao wrote:
> > > > +static int iommufd_fault_iopf_enable(struct iommufd_device *idev)
> &
On 9/20/24 11:51 AM, Jason Merrill wrote:
On 9/19/24 4:37 PM, Jakub Jelinek wrote:
On Thu, Sep 19, 2024 at 10:21:15AM -0400, Jason Merrill wrote:
On 9/19/24 7:57 AM, Richard Biener wrote:
On Wed, Sep 18, 2024 at 6:22 PM Jason Merrill wrote:
Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap
+1 (binding)
On Tue, Oct 15, 2024 at 6:43 PM Jan Høydahl wrote:
>
> +1 (binding)
>
> Jan
>
> > 15. okt. 2024 kl. 23:42 skrev Houston Putman :
> >
> > Hey everyone,
> >
> > A little while back, I made a thread asking opinions on cutting the 8.x
> > Solr support after 8.11.4 was released. Since the
On 15/10/24 19:29, Daniel Dalton wrote:
Just an update here I was able to get this working by using the new
brltty-term script suggested by Dave instead of the old screen driver.
This raises the question whether there's a way to install the necessary
kernel modules in your environment to ena
e a sticking point in these discussions, having a
way to make any big folio HVO optimized (and undo it) then put hugetlb
on top of that would be a nice refactoring.
Jason
On Sat, Oct 12, 2024 at 09:21:41AM +0200, Lorenz (xha) wrote:
> gprof(1) mentions that the "-pg" flag in cc(1) can be used to create
> a gmon.out file. this is not documented (in the cc man page) and
> results in a segfault:
>
hi.
i can;t address the segfault issue, but for the doc part, this se
On 15/10/24 19:13, Caitlyn Furness wrote:
Lots of times when I get the error, I only have one thing open or am doing a
quick look at a file... So confusing! 🙂
It could be a service running in the background. You'll need to examine
memory statistics. Activity Monitor is the obvious tool for t
Hi Daniel,
On 2024/10/4 下午 11:57, Daniel Henrique Barboza wrote:
From: Tomasz Jeznach
The RISC-V IOMMU spec predicts that the IOMMU can use translation caches
to hold entries from the DDT. This includes implementation for all cache
commands that are marked as 'not implemented'.
There are some
_MODE_3LVL) {
+ok = old_mode == RISCV_IOMMU_DDTP_MODE_OFF ||
+ old_mode == RISCV_IOMMU_DDTP_MODE_BARE;
+}
+
+if (ok) {
+/* clear reserved and busy bits, report back sanitized version */
+new_ddtp = set_field(new_ddtp & RISCV_IOMMU_DDTP_PPN,
Thanks Scott! Yes, that's the table. We just need to replace CWE-A/B/C with
the actual CWE #s and that will give us a good mapping. I think the
Observed Examples section of the transient execution weaknesses may already
have some of this mapping too.
@Fung, Jason M yes this would definitely
Good points, team.
I would like to clarify that given HW issues are outnumbered by SW issues
(thankfully), rather than taking all CVEs into consideration, we should look
into the subset of CVEs that are HW orientated and see which CWEs stand out to
be the recurring patterns. That’s why Jason
jasonmolenda wrote:
Alex had a PR a month ago https://github.com/llvm/llvm-project/pull/106791 that
got reverted from the same test failing on x86, I tried to repo the failure a
few times on an intel mac and never succeeded. I'll try again with your patch
when I have that set up. If this tes
jasonmolenda wrote:
Very nice! And now we'll see what all the CI bots think of this change. :)
https://github.com/llvm/llvm-project/pull/110646
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/l
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/110646
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
IO is different. I don't want
to write off the AIO concept over this one issue.
Jason Szumlanski
Principal Solar Designer | Florida Solar Design Group
NABCEP Certified Solar Professional (PVIP)
Florida State Certified Solar Contractor CVC56956
Florida Certified Electrical Contractor EC13013208
On M
n the competition. We’d be happy to help.
>
>
>
> -Arun Kanuparthi
>
>
>
> *From:* Steven M Christey
> *Sent:* Tuesday, October 15, 2024 9:03 AM
> *To:* Oberg, Jason ; Fung, Jason M <
> jason.m.f...@intel.com>
> *Cc:* Ford, Thomas ; HW CWE Special Interest Gr
mber and the trade-off is we lose some usable video memory, at around
> (549-256)MB so far.
I think that is where you have to end up as we don't really want
probe-time configurables, and consider later updating how the FW works
to make this more optimal.
Jason
1 - 100 of 2424 matches
Mail list logo
