On 6/14/24 09:14, Borislav Petkov wrote:
> On Fri, Jun 14, 2024 at 09:03:22AM -0700, Dave Hansen wrote:
...
>> You need to zero out all of 'args' somehow.
>
> You mean like this:
>
> struct tdx_module_args args = {};
>
> ?
Yes, or do all the assignme
On 6/13/24 12:16, Alexey Makhalov wrote:
> +unsigned long vmware_tdx_hypercall(unsigned long cmd,
> +unsigned long in1, unsigned long in3,
> +unsigned long in4, unsigned long in5,
> +u32 *out1, u32 *out2
args->r12 = VMWARE_HYPERVISOR_MAGIC;
> + args->r13 = cmd;
> + args->r15 = 0; /* CPL */
> +
> + __tdx_hypercall(args);
> +
> + return args->r12;
> +}
> +EXPORT_SYMBOL_GPL(vmware_tdx_hypercall);
> +#endif
This is the kind of wrapper that I was hoping for. Thanks.
Acked-by: Dave Hansen
On 12/5/23 23:15, Alexey Makhalov wrote:
> +#ifdef CONFIG_INTEL_TDX_GUEST
> +/* Export tdx hypercall and allow it only for VMware guests. */
> +void vmware_tdx_hypercall_args(struct tdx_module_args *args)
> +{
> + if (hypervisor_is_type(X86_HYPER_VMWARE))
> + __tdx_hypercall(args);
On 12/5/23 13:41, Alexey Makhalov wrote:
>> I don't really like it much. This does a generic thing (make a TDX
>> hypercall) with a specific name ("vmware_"). If you want to make an
>> argument that a certain chunk of the __tdx_hypercall() space is just for
>> VMWare and you also add a VMWare-spe
On 12/4/23 02:31, Borislav Petkov wrote:
> On Fri, Dec 01, 2023 at 03:24:52PM -0800, Alexey Makhalov wrote:
>> +#ifdef CONFIG_INTEL_TDX_GUEST
>> +/* __tdx_hypercall() is not exported. So, export the wrapper */
>> +void vmware_tdx_hypercall_args(struct tdx_module_args *args)
>> +{
>> +__tdx_hype
On 3/7/22 03:27, Jarkko Sakkinen wrote:
> But e.g. in __mm_populate() anything with (VM_IO | VM_PFNMAP) gets
> filtered out and never reach that function.
>
> I don't know unorthodox that'd be but could we perhaps have a VM
> flag for SGX?
SGX only works on a subset of the chips from one vendor o
On 3/6/22 15:24, Andrew Morton wrote:
> On Sun, 6 Mar 2022 05:26:55 +0200 Jarkko Sakkinen wrote:
>
>> Sometimes you might want to use MAP_POPULATE to ask a device driver to
>> initialize the device memory in some specific manner. SGX driver can use
>> this to request more memory by issuing ENCLS
t pci_device_id intel_early_ids[]
> __initconst = {
> INTEL_RKL_IDS(&gen11_early_ops),
> INTEL_ADLS_IDS(&gen11_early_ops),
> INTEL_ADLP_IDS(&gen11_early_ops),
> + INTEL_RPLS_IDS(&gen11_early_ops),
> };
For arch/x86 purposes:
Acked-by: Dave Hansen
On 11/12/21 12:09 PM, Lucas De Marchi wrote:
> The intention was to merge this through the tip tree. Although now I'm
> not sure. Options:
>
> 1) take the first patch through the drm-intel tree and apply the
> second patch later
> 2) take everything through the drm tree
> 3) tak
On 3/24/21 1:22 PM, Thomas Hellström (Intel) wrote:
>> We also have not been careful at *all* about how _PAGE_BIT_SOFTW* are
>> used. It's quite possible we can encode another use even in the
>> existing bits.
>>
>> Personally, I'd just try:
>>
>> #define _PAGE_BIT_SOFTW5 57 /* availab
On 3/24/21 3:05 AM, Thomas Hellström (Intel) wrote:
> Yes, I agree. Seems like the special (SW1) is available also for huge
> page table entries on x86 AFAICT, although just not implemented.
> Otherwise the SW bits appear completely used up.
Although the _PAGE_BIT_SOFTW* bits are used up, there's
On 10/12/20 9:19 AM, Eric Biggers wrote:
> On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
>>> And I still don't really understand. After this patchset, there is still
>>> code
>>> nearly identical to the above (doing a temporary mapping just for a memcpy)
>>> that
>>> would still be
Thomas, this series has garnered a nak and a whole pile of thoroughly
confused reviewers.
Could you take another stab at this along with a more ample changelog
explaining the context of the problem? I suspect that's a better place
to start than having us all piece together the disparate parts of
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
> So the question here should really be, can we determine already at mmap
> time whether backing memory will be unencrypted and adjust the *real*
> vma->vm_page_prot under the mmap_sem?
>
> Possibly, but that requires populating the buffer with m
On 9/3/19 12:51 PM, Daniel Vetter wrote:
>> The thing we need to stop is having mixed encryption rules under one VMA.
> The point here is that we want this. We need to be able to move the
> buffer between device ptes and system memory ptes, transparently,
> behind userspace back, without races. And
This whole thing looks like a fascinating collection of hacks. :)
ttm is taking a stack-alllocated "VMA" and handing it to vmf_insert_*()
which obviously are expecting "real" VMAs that are linked into the mm.
It's extracting some pgprot_t information from the real VMA, making a
psuedo-temporary VM
On 9/3/19 6:15 AM, Thomas Hellström (VMware) wrote:
> The force_dma_unencrypted symbol is needed by TTM to set up the correct
> page protection when memory encryption is active. Export it.
It would be great if this had enough background that I didn't have to
look at patch 4 to figure out what TTM
On 8/1/19 5:38 AM, Kevin Brodsky wrote:
> This patch series only changes what is allowed or not at the syscall
> interface. It does not change the address space size. On arm64, TBI (Top
> Byte Ignore) has always been enabled for userspace, so it has never been
> possible to use the upper 8 bits of
On 8/1/19 5:48 AM, Andrey Konovalov wrote:
> On Thu, Aug 1, 2019 at 2:11 PM Kevin Brodsky wrote:
>> On 31/07/2019 17:50, Dave Hansen wrote:
>>> On 7/23/19 10:58 AM, Andrey Konovalov wrote:
>>>> The mmap and mremap (only new_addr) syscalls do not currentl
On 7/23/19 10:58 AM, Andrey Konovalov wrote:
> +long set_tagged_addr_ctrl(unsigned long arg)
> +{
> + if (!tagged_addr_prctl_allowed)
> + return -EINVAL;
> + if (is_compat_task())
> + return -EINVAL;
> + if (arg & ~PR_TAGGED_ADDR_ENABLE)
> + return -E
On 7/23/19 10:58 AM, Andrey Konovalov wrote:
> The mmap and mremap (only new_addr) syscalls do not currently accept
> tagged addresses. Architectures may interpret the tag as a background
> colour for the corresponding vma.
What the heck is a "background colour"? :)
___
On 02/01/2017 12:52 AM, Daniel Vetter wrote:
> On Tue, Jan 31, 2017 at 04:27:14PM -0800, Dave Hansen wrote:
>> I added some printk()s all over and gathered a bit more information
>> about what's going on. It looks like the display doesn't work until the
>> drm co
I added some printk()s all over and gathered a bit more information
about what's going on. It looks like the display doesn't work until the
drm connector code cleans up the *old* connector. For some reason, it
isn't motivated to do that until I go to the console and back.
In this case, the displ
On 01/30/2017 01:12 AM, Daniel Vetter wrote:
> On Thu, Jan 26, 2017 at 12:34:29PM -0800, Dave Hansen wrote:
...
>> And, yeah, I think it just gets the connected status wrong. The
>> connector is still there.
>
> Hm, I thought I replied here but I didn't:
> - Is this
On 01/25/2017 07:38 AM, Daniel Vetter wrote:
> On Wed, Jan 25, 2017 at 07:20:45AM -0800, Dave Hansen wrote:
>> On 01/24/2017 10:21 PM, Daniel Vetter wrote:
>>> Hi Dave,
>>>
>>> Still waiting for your testing results on this one here ...
>>
>> It&
On 01/24/2017 10:21 PM, Daniel Vetter wrote:
> Hi Dave,
>
> Still waiting for your testing results on this one here ...
It's definitely stable with that patch applied. No more crashes.
But, it's also definitely having difficulty re-probing to find the
monitor that's attached to the dock in some
On 01/10/2017 11:43 PM, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote:
>> On 01/10/2017 02:31 AM, Daniel Vetter wrote:
>>> commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e
>>> Author: Daniel Vetter
>>> Date: Sun Dec 18
On 01/11/2017 07:39 AM, Daniel Vetter wrote:
> Hm, just cherry-picked it on top of Linus' latest 4.10 git, applies
> cleanly there. The substituation was for 4.9. I can send you the patch
> here, but seems all fine from what I can tell ...
All of the printk's that I added were making it fail to ap
On 01/10/2017 02:31 AM, Daniel Vetter wrote:
> commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e
> Author: Daniel Vetter
> Date: Sun Dec 18 14:35:45 2016 +0100
>
> drm: prevent double-(un)registration for connectors
>
> Lack of that would perfectly explain that oops ... Otherwise still no id
On 01/09/2017 08:59 AM, Daniel Vetter wrote:
> On Mon, Jan 9, 2017 at 5:50 PM, Dave Hansen wrote:
>> On 01/09/2017 08:41 AM, Daniel Vetter wrote:
>>> On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen
>>> wrote:
>>>> Well, now I found where the -2 comes fro
On 01/09/2017 08:59 AM, Daniel Vetter wrote:
> On Mon, Jan 9, 2017 at 5:50 PM, Dave Hansen wrote:
>> On 01/09/2017 08:41 AM, Daniel Vetter wrote:
>>> On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen
>>> wrote:
>>>> Well, now I found where the -2 comes fro
On 01/09/2017 08:41 AM, Daniel Vetter wrote:
> On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen wrote:
>> Well, now I found where the -2 comes from.
>> intel_dp_register_mst_connector() calls drm_connector_register(), which
>> fails to add the kobject (warning below). Bu
On 01/09/2017 05:40 AM, Dave Hansen wrote:
> Is there some stable code to go back to here? Or, is there something
> about my configuration that's unique? I really wonder why nobody else
> is running into this.
Here are a couple of similar-looking reports, if that
Well, now I found where the -2 comes from.
intel_dp_register_mst_connector() calls drm_connector_register(), which
fails to add the kobject (warning below). But, it does zero error
checking on the drm_connector_register() call and leaves the
partially-constructed connector in place.
The next time
On 01/09/2017 02:15 AM, Daniel Vetter wrote:
...
> Can you pls do some printk tracing to make sure that without your patch
> we're indeed releasing the same connector twice from this loop? I suspect
> you're just ever-so-slightly shifting the timing and things blow up
> somewhre else. But no idea w
My Thinkpad x260 doesn't like to be unplugged from its dock. I don't
think this is a new bug. It's happening on my distro's 4.4 kernel
as well.
The actual oops is in device_del(). It appears to have been passed a
null 'struct device *'.
There appears to have been a race _around_ here fixed in
On 11/22/2016 11:49 PM, Daniel Vetter wrote:
> Yes, agreed. My idea with exposing vram sections using numa nodes wasn't
> to reuse all the existing allocation policies directly, those won't work.
> So at boot-up your default numa policy would exclude any vram nodes.
>
> But I think (as an -mm laym
On 10/19/2016 10:01 AM, Michal Hocko wrote:
> The question I had earlier was whether this has to be an explicit FOLL
> flag used by g-u-p users or we can just use it internally when mm !=
> current->mm
The reason I chose not to do that was that deferred work gets run under
a basically random 'curr
On 10/19/2016 02:07 AM, Michal Hocko wrote:
> On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
>> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
>>> I am wondering whether we can go further. E.g. it is not really clear to
>>> me whether we need an explicit FOLL_REMOTE when we can in
On 10/11/2016 04:50 PM, Ruchi Kandoi wrote:
> Any process holding a reference to these buffers will keep the kernel from
> reclaiming its backing pages. mm counters don't provide a complete picture of
> these allocations, since they only account for pages that are mapped into a
> process's address
I've been seeing a little goofiness with i915 video under the 3.7-rc's.
It looks like I'm seeing two separate issues. One, that the video
hardware hangs, spits some errors in dmesg, and then video acceleration
seems to stop working. Two, when it does this, apport goes digging in
debugfs for infor
I've been seeing a little goofiness with i915 video under the 3.7-rc's.
It looks like I'm seeing two separate issues. One, that the video
hardware hangs, spits some errors in dmesg, and then video acceleration
seems to stop working. Two, when it does this, apport goes digging in
debugfs for infor
43 matches
Mail list logo
