On Tue, May 05 2020 at 17:00:32 -0500, Clay Harris quoth thus:
> On Wed, May 06 2020 at 00:38:05 +0300, Pavel Begunkov quoth thus:
>
> > On 06/05/2020 00:10, Clay Harris wrote:
> > > On Mon, May 04 2020 at 22:39:35 +0300, Pavel Begunkov quoth thus:
> > >
> > >> do_splice() is used by io_uring, a
On Tue, 2020-05-05 at 09:46 -0600, Jonathan Corbet wrote:
> On Thu, 30 Apr 2020 19:12:38 -0300
> Vitor Massaru Iha wrote:
>
> > This fixes:
> >
> > Documentation/s390/vfio-ap.rst:488: WARNING: duplicate label
> > s390/vfio-ap:guest2, other instance in
> > /home/iha/sdb/opensource/lkmp/linux_doc/
This code generated by Clang here is the unfortunate side-effect of a
bug introduced during Clang-10's development phase. From discussion
with Kees on the links Nick mentioned, I surmise that FORTIFY in the
kernel never worked as well for Clang as it does for GCC today. In
many cases, it'd compile
On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
wrote:
> I believe these issues are one in the same. I did a reverse bisect with
> Arnd's test case and converged on George's first patch:
>
> https://github.com/llvm/llvm-project/commit/2dd17ff08165e6118e70f00e22b2c36d2d4e0a9a
>
> I think that in l
The original Memory Bandwidth Monitoring (MBM) architectural
definition defines counters of up to 62 bits in the IA32_QM_CTR MSR,
and the first-generation MBM implementation uses 24 bit counters.
Software is required to poll at 1 second or faster to ensure that
data is retrieved before a counter ro
The original Memory Bandwidth Monitoring (MBM) architectural
definition defines counters of up to 62 bits in the
IA32_QM_CTR MSR while the first-generation MBM implementation
uses statically defined 24 bit counters.
The MBM CPUID enumeration properties have been expanded to include
the MBM counter
The original Memory Bandwidth Monitoring (MBM) architectural
definition defines counters of up to 62 bits in the
IA32_QM_CTR MSR while the first-generation MBM implementation
uses statically defined 24 bit counters.
Expand the MBM CPUID enumeration properties to include the MBM
counter width. The
V1 submission available from:
https://lore.kernel.org/lkml/cover.1585763047.git.reinette.cha...@intel.com
Changes since V1:
- Add four new preparatory patches to this series to eliminate the
unnecessary reading of monitoring properties from every CPU (reading from
one CPU is sufficient) and re
The function determining a platform's support and properties of cache
occupancy and memory bandwidth monitoring (properties of
X86_FEATURE_CQM_LLC) can be found among the common CPU code. After
the feature's properties is populated in the per-CPU data the resctrl
subsystem is the only consumer (via
The cache and memory bandwidth monitoring properties are read using
CPUID on every CPU. After the information is read from the system a
sanity check is run to (1) ensure that the RMID data is initialized
for the boot CPU in case the information was not available on the boot
CPU and (2) the boot CPU
Cache and memory bandwidth monitoring are features that are part of
x86 CPU resource control that is supported by the resctrl subsystem.
The monitoring properties are obtained via CPUID from every CPU
and only used within the resctrl subsystem where the properties are
only read from boot_cpu_data.
asm/resctrl_sched.h is dedicated to the code used for configuration
of the CPU resource control state when a task is scheduled.
Rename resctrl_sched.h to resctrl.h in preparation of additions that
will no longer make this file dedicated to work done during scheduling.
No functional change.
Sugge
On Fri 24 Apr 13:01 PDT 2020, Mathieu Poirier wrote:
> In scenarios where the remote processor's lifecycle is entirely
> managed by another entity there is no point in allocating memory for
> a firmware name since it will never be used. The same goes for a core
> set of operations.
>
> As such i
The mm-of-the-moment snapshot 2020-05-05-15-28 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You wi
The PCI Code and ID Assignment Specification changed capability ID 0
from reserved to a NULL capability in the v1.1 revision. The NULL
capability is defined to include only the 16-bit capability header,
ie. only the ID and next pointer. Unfortunately vfio-pci creates a
map of config space, where
Laurent,
On Tue, May 5, 2020 at 2:35 PM Laurent Pinchart
wrote:
>
> Hi Doug,
>
> Thank you for the patch.
>
> On Thu, Apr 30, 2020 at 12:46:15PM -0700, Douglas Anderson wrote:
> > This moves the bindings over, based a lot on toshiba,tc358768.yaml.
> > Unless there's someone known to be better, I'
On Tue, May 05, 2020 at 03:02:16PM -0700, 'Nick Desaulniers' via Clang Built
Linux wrote:
> On Tue, May 5, 2020 at 2:55 PM Jason A. Donenfeld wrote:
> >
> > clang-10 has a broken optimization stage that doesn't enable the
> > compiler to prove at compile time that certain memcpys are within
> > b
On Wed, May 06, 2020 at 12:05:04AM +0200, Thomas Gleixner wrote:
> "Paul E. McKenney" writes:
>
> > On Tue, May 05, 2020 at 03:44:05PM +0200, Thomas Gleixner wrote:
> >> Interrupts and exceptions invoke rcu_irq_enter() on entry and need to
> >> invoke rcu_irq_exit() before they either return to t
Hi Borislav,
On 5/4/2020 9:19 PM, Reinette Chatre wrote:
> On 5/4/2020 12:56 AM, Borislav Petkov wrote:
>> Hi,
>>
>> On Sun, May 03, 2020 at 11:51:00AM -0700, Reinette Chatre wrote:
>>> I am struggling with what should follow ...
>>
>> Since a diff is better than a thousand words :-) see below.
>>
On 05/05/2020 23:01:19+0200, Rasmus Villemoes wrote:
> Thanks for the quick replies, both. Unfortunately, being able to read BF
> from linux is not relevant to us - all the handling happens early in the
> bootloader (including clearing BF, so that we can detect that the
> previous boot failed only
On 06/05/2020 01:00, Clay Harris wrote:
> On Wed, May 06 2020 at 00:38:05 +0300, Pavel Begunkov quoth thus:
>
>> On 06/05/2020 00:10, Clay Harris wrote:
>>> On Mon, May 04 2020 at 22:39:35 +0300, Pavel Begunkov quoth thus:
>>>
do_splice() is used by io_uring, as will be do_tee(). Move f_mode
On Fri 24 Apr 13:01 PDT 2020, Mathieu Poirier wrote:
> When synchronizing with a remote processor, it is entirely possible that
> the remoteproc core is not the life cycle manager. In such a case core
> operations don't exist and should not be called.
>
Why would the core call these functions i
The 'clk' and 'irq' fields were only ever used in the probe function.
Therefore they can be moved to be simple local variables of the probe
function.
Signed-off-by: Paul Cercueil
---
drivers/rtc/rtc-jz4740.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff
We can write the wakeup timing parameters as soon as the driver probes,
there's no need to wait the very last moment.
Signed-off-by: Paul Cercueil
---
drivers/rtc/rtc-jz4740.c | 95 +++-
1 file changed, 44 insertions(+), 51 deletions(-)
diff --git a/drivers/r
The code was returning -ENOENT on any error of platform_get_irq(), even
if it returned a different error.
Signed-off-by: Paul Cercueil
---
drivers/rtc/rtc-jz4740.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-jz4740.c b/drivers/rtc/rtc-jz4740.c
index 3193eb
With the recent work on supporting Device Tree on Ingenic SoCs, no
driver ever probes from platform code anymore, so we can clean a bit
this driver by removing the non-devicetree paths.
Signed-off-by: Paul Cercueil
---
drivers/rtc/Kconfig | 1 +
drivers/rtc/rtc-jz4740.c | 20 +++---
The regulator register specifies how many input clock cycles (minus one)
are contained in one tick of the 1 Hz clock.
Since this register can contain bogus values after the system boots, it
needs to be reset in the probe register, otherwise the RTC may count way
to slow or way too fast.
Signed-of
It makes no sense to request a clock and not enable it even though the
hardware is being used. So the driver now enables the clock in the
probe. Besides, now we can properly handle errors.
Signed-off-by: Paul Cercueil
---
drivers/rtc/rtc-jz4740.c | 19 +--
1 file changed, 17 inse
Clean a bit the probe function by adding a local struct device *dev
variable.
Signed-off-by: Paul Cercueil
---
drivers/rtc/rtc-jz4740.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/rtc/rtc-jz4740.c b/drivers/rtc/rtc-jz4740.c
index 9
Hi Eizan,
Thank you for your patch.
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 9:45:
>
> Broadly, this patch (1) adds a driver for various MTK MDP components to
> go alongside the main MTK MDP driver, and (2) hooks them all together
> using the component framework.
>
> (1) Up u
On Fri, May 01, 2020 at 10:28:56PM +0200, Peter Zijlstra wrote:
> +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> +
> +struct static_call_mod {
> + struct static_call_mod *next;
> + struct module *mod; /* for vmlinux, mod == NULL */
> + struct static_call_site *sites;
> +};
> +
> +struct stati
On Mon, May 04, 2020 at 01:14:59PM +0200, Arnaud POULIQUEN wrote:
> hi Mathieu,
>
> On 4/30/20 9:57 PM, Mathieu Poirier wrote:
> > On Tue, Apr 28, 2020 at 07:27:27PM +0200, Arnaud POULIQUEN wrote:
> >>
> >>
> >> On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> >>> Call the right core function based o
On 05/05/2020 23:30:18+0200, Rasmus Villemoes wrote:
> On 05/05/2020 22.13, Alexandre Belloni wrote:
> > Add support for the RTC_VL_BACKUP_SWITCH flag to report battery switch over
> > events.
> >
> > Signed-off-by: Alexandre Belloni
> > ---
> > drivers/rtc/rtc-pcf2127.c | 16
>
"Paul E. McKenney" writes:
> On Tue, May 05, 2020 at 03:44:05PM +0200, Thomas Gleixner wrote:
>> Interrupts and exceptions invoke rcu_irq_enter() on entry and need to
>> invoke rcu_irq_exit() before they either return to the interrupted code or
>> invoke the scheduler due to preemption.
>>
>> Th
This single fix address two issues on machines with nau88125:
1) Audio distortion, due to lack of required clock rate on MCLK line
2) Loud audible "pops" on headphones if there is no sysclk during nau8825
playback power up sequence
Explanation for:
1) Due to Skylake HW limitation, MCLK pi
On Tue, May 05, 2020 at 01:41:44PM -0700, Kees Cook wrote:
> On Tue, May 05, 2020 at 08:34:41AM +0200, Greg KH wrote:
> > On Mon, May 04, 2020 at 09:59:03PM +, Luis Chamberlain wrote:
> > > On Mon, May 04, 2020 at 01:32:07PM -0700, Kees Cook wrote:
> > > > On Mon, May 04, 2020 at 07:59:37PM +00
On Mon, May 04, 2020 at 01:34:43PM +0200, Arnaud POULIQUEN wrote:
>
>
> On 4/30/20 10:23 PM, Mathieu Poirier wrote:
> > On Wed, Apr 29, 2020 at 10:19:49AM +0200, Arnaud POULIQUEN wrote:
> >>
> >>
> >> On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> >>> The remoteproc core must not allow function rp
On Tue, May 5, 2020 at 2:55 PM Jason A. Donenfeld wrote:
>
> clang-10 has a broken optimization stage that doesn't enable the
> compiler to prove at compile time that certain memcpys are within
> bounds, and thus the outline memcpy is always called, resulting in
> horrific performance, and in some
On Tue, May 05, 2020 at 03:44:05PM +0200, Thomas Gleixner wrote:
> Interrupts and exceptions invoke rcu_irq_enter() on entry and need to
> invoke rcu_irq_exit() before they either return to the interrupted code or
> invoke the scheduler due to preemption.
>
> The general assumption is that RCU idl
On Wed, May 06 2020 at 00:38:05 +0300, Pavel Begunkov quoth thus:
> On 06/05/2020 00:10, Clay Harris wrote:
> > On Mon, May 04 2020 at 22:39:35 +0300, Pavel Begunkov quoth thus:
> >
> >> do_splice() is used by io_uring, as will be do_tee(). Move f_mode
> >> checks from sys_{splice,tee}() to do_{s
On Tue, May 05, 2020 at 11:45:07AM -0400, Pavel Tatashin wrote:
> Add a new field to pstore_info that passes information about kmesg dump
> maximum reason.
>
> This allows a finer control of what kmesg dumps are stored on pstore
> device.
>
> Those clients that do not explicitly set this field (k
On Tue, May 05, 2020 at 08:09:39AM +0200, Cornelia Huck wrote:
> External email: Use caution opening links or attachments
>
>
> On Mon, 4 May 2020 17:03:54 -0600
> Alex Williamson wrote:
>
> > On Mon, 4 May 2020 15:08:08 -0700
> > Neo Jia wrote:
> >
> > > On Mon, May 04, 2020 at 12:52:53PM -06
Rather than calling remap_pfn_range() when a region is mmap'd, setup
a vm_ops handler to support dynamic faulting of the range on access.
This allows us to manage a list of vmas actively mapping the area that
we can later use to invalidate those mappings. The open callback
invalidates the vma rang
clang-10 has a broken optimization stage that doesn't enable the
compiler to prove at compile time that certain memcpys are within
bounds, and thus the outline memcpy is always called, resulting in
horrific performance, and in some cases, excessive stack frame growth.
Here's a simple reproducer:
Accessing the disabled memory space of a PCI device would typically
result in a master abort response on conventional PCI, or an
unsupported request on PCI express. The user would generally see
these as a -1 response for the read return data and the write would be
silently discarded, possibly with
v2:
Locking in 3/ is substantially changed to avoid the retry scenario
within the fault handler, therefore a caller who does not allow retry
will no longer receive a SIGBUS on contention. IOMMU invalidations
are still not included here, I expect that will be a future follow-on
change as we're not
With conversion to follow_pfn(), DMA mapping a PFNMAP range depends on
the range being faulted into the vma. Add support to manually provide
that, in the same way as done on KVM with hva_to_pfn_remapped().
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio_iommu_type1.c | 36 +++
"Paul E. McKenney" writes:
> On Tue, May 05, 2020 at 03:16:14PM +0200, Thomas Gleixner wrote:
>> RCU is watching for:
>>
>> #1 The vCPU exited and current is definitely not the idle task
>>
>> #2a The #PF entry code on the guest went through enter_from_user_mode()
>> which reactivates
On Tue, May 5, 2020 at 3:48 PM Nick Desaulniers wrote:
>
> + Kees, George, who have started looking into this, too.
I have a smaller reproducer and analysis I'll send out very shortly.
+ Kees, George, who have started looking into this, too.
On Tue, May 5, 2020 at 2:40 PM Jason A. Donenfeld wrote:
>
> As discussed on IRC, this issue here isn't specific to this file, but
> rather fortify source has some serious issues on clang-10, everywhere
> in the kernel, and we should probab
Ashok,
"Raj, Ashok" writes:
> On Tue, May 05, 2020 at 09:36:04PM +0200, Thomas Gleixner wrote:
>> The way it works is:
>>
>> 1) New vector on different CPU is allocated
>>
>> 2) New vector is installed
>>
>> 3) When the first interrupt on the new CPU arrives then the cleanup
>>
Hi Eizan,
Thank you for your patch.
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 6:02:
>
> The functions mtk_mdp_register/unregister_component have been created to
> add / remove items from the list of components.
>
> This will eventually enable us to specify a list of components
Hi Eizan,
Thank you for your patch. One trivial comment below ...
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 6:01:
>
> These fields are not used and can be removed.
>
> Signed-off-by: ei...@chromium.org
Malformatted Signed-off-by tag. Drop it.
> Signed-off-by: Eizan Miyamoto
Hi Eizan,
Thank you for your patch.
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 6:01:
>
> This is a cleanup to better handle errors during MDP probe.
>
> Signed-off-by: ei...@chromium.org
> Signed-off-by: Eizan Miyamoto
Same comment as the first patch. You should probably fix
Hi Eizan,
Thank you for your patch.
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 6:01:
>
> This is a cleanup to better handle errors during MDP probe.
>
> Signed-off-by: ei...@chromium.org
> Signed-off-by: Eizan Miyamoto
Ditto
> ---
>
> drivers/media/platform/mtk-mdp/mtk_mdp_
Hi Eizan,
Thank you for your patch.
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 6:02:
>
> Since components are registered in a list, the numeric component id that
> specified a location in an array is not necessary.
>
> Signed-off-by: ei...@chromium.org
> Signed-off-by: Eizan Mi
Hi Eizan,
Thank you for your patch. Two trivial comments, see below ...
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 4:07:
>
> From: Francois Buergisser
>
> The mtk-mdp driver uses states to check if the formats have been set
> on the capture and output when turning the streamin
On Mon, May 04, 2020 at 01:57:59PM +0200, Arnaud POULIQUEN wrote:
>
>
> On 4/30/20 10:42 PM, Mathieu Poirier wrote:
> > On Wed, Apr 29, 2020 at 11:22:28AM +0200, Arnaud POULIQUEN wrote:
> >>
> >>
> >> On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> >>> Introducting function rproc_set_state_machine(
As discussed on IRC, this issue here isn't specific to this file, but
rather fortify source has some serious issues on clang-10, everywhere
in the kernel, and we should probably disable it globally for this
clang version. I'll follow up with some more info in a different
patch.
On 06/05/2020 00:10, Clay Harris wrote:
> On Mon, May 04 2020 at 22:39:35 +0300, Pavel Begunkov quoth thus:
>
>> do_splice() is used by io_uring, as will be do_tee(). Move f_mode
>> checks from sys_{splice,tee}() to do_{splice,tee}(), so they're
>> enforced for io_uring as well.
>
> I'm not seein
Hi Doug,
Thank you for the patch.
On Thu, Apr 30, 2020 at 12:46:13PM -0700, Douglas Anderson wrote:
> In the cases where there is no connector in a system there's no great
> place to put "hpd-gpios". As per discussion [1] the best place to put
> it is in the panel. Add this to the device tree b
Hi Doug,
Thank you for the patch.
On Thu, Apr 30, 2020 at 12:46:16PM -0700, Douglas Anderson wrote:
> The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
> HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
> because of excessive debouncing in hardware. Specifical
On Tue, May 5, 2020 at 6:57 PM Pavel Machek wrote:
> On Tue 2020-05-05 11:32:27, Sasha Levin wrote:
> > On Tue, May 05, 2020 at 05:05:37PM +0300, Andy Shevchenko wrote:
...
> > I'm a bit confused about this too. Maybe it's too early in the morning,
> > so I wrote this little test program:
> >
>
Hi Doug,
Thank you for the patch.
On Thu, Apr 30, 2020 at 12:46:15PM -0700, Douglas Anderson wrote:
> This moves the bindings over, based a lot on toshiba,tc358768.yaml.
> Unless there's someone known to be better, I've set the maintainer in
> the yaml as the first person to submit bindings.
>
>
On Tue, 5 May 2020 at 02:07, Arnaud POULIQUEN wrote:
>
> Hi Mathieu,
>
>
>
> On 5/4/20 11:58 PM, Mathieu Poirier wrote:
> > After adding support for rpmsg device name extension, this patch
> > provides a function that returns the extension portion of an rpmsg
> > device name. That way users of th
On 05/05/2020 22.13, Alexandre Belloni wrote:
> Add support for the RTC_VL_BACKUP_SWITCH flag to report battery switch over
> events.
>
> Signed-off-by: Alexandre Belloni
> ---
> drivers/rtc/rtc-pcf2127.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a
On Tue, May 05, 2020 at 02:46:01PM -0500, Eric W. Biederman wrote:
>
> There is and has been for a very long time been a lot more going on in
> flush_old_exec than just flushing the old state. After the movement
> of code from setup_new_exec there is a whole lot more going on than
> just flushing
On Tue, May 05, 2020 at 02:45:33PM -0500, Eric W. Biederman wrote:
>
> The current idiom for the callers is:
>
> flush_old_exec(bprm);
> set_personality(...);
> setup_new_exec(bprm);
>
> In 2010 Linus split flush_old_exec into flush_old_exec and
> setup_new_exec. With the intention that setup_n
Hi,
On Tue, May 5, 2020 at 2:21 PM Sam Ravnborg wrote:
>
> Hi Dough.
>
> > >
> > > If we don't want to test that, I would at least document it in the DT
> > > bindings. It will be a good occasion to switch the bindings to YAML ;-)
> >
> > Interesting that you bring this up. Conversion to yaml is
From: Bhupesh Sharma
Date: Wed, 6 May 2020 00:34:40 +0530
> -#define NUM_RX_BDS_DEF ((u16)BIT(10) - 1)
> +#define NUM_RX_BDS_DEF ((is_kdump_kernel()) ? ((u16)BIT(6) -
> 1) : ((u16)BIT(10) - 1))
These parenthesis are very excessive and unnecessary. At the
very least
On Tue, May 05, 2020 at 05:09:56PM -0400, Tejun Heo wrote:
> Hello,
>
> On Tue, May 05, 2020 at 05:01:18PM -0400, J. Bruce Fields wrote:
> > On Mon, May 04, 2020 at 10:15:14PM -0400, J. Bruce Fields wrote:
> > > Though now I'm feeling greedy: it would be nice to have both some kind
> > > of global
Hi,
On Tue, May 5, 2020 at 2:14 PM Laurent Pinchart
wrote:
>
> > I'll add this documentation into the comments of the yaml, but I'm not
> > going to try to implement enforcement at the yaml level.
>
> Why not ? :-)
Because trying to describe anything in the yaml bindings that doesn't
fit in the
On Tue, 5 May 2020 14:02:53 -0700, Florian Fainelli
wrote:
> If we are probed through platform_data we would be intentionally
> dropping the reference count on master after dev_to_net_device()
> incremented it. If we are probed through Device Tree,
> of_find_net_device() does not do a dev_hold()
From: Ashish Kalra
Reset the host's page encryption bitmap related to kernel
specific page encryption status settings before we load a
new kernel by kexec. We cannot reset the complete
page encryption bitmap here as we need to retain the
UEFI/OVMF firmware specific settings.
The host's page encr
From: Ashish Kalra
For source VM, live migration feature is enabled explicitly
when the guest is booting, for the incoming VM(s) it is implied.
This is required for handling A->B->C->... VM migrations case.
Signed-off-by: Ashish Kalra
---
arch/x86/kvm/svm/sev.c | 7 +++
1 file changed, 7 i
From: Ashish Kalra
Ensure that _bss_decrypted section variables such as hv_clock_boot and
wall_clock are marked as decrypted in the page encryption bitmap if
sev liv migration is supported.
Signed-off-by: Ashish Kalra
---
arch/x86/kernel/kvmclock.c | 12
1 file changed, 12 inserti
Hi Dough.
> >
> > If we don't want to test that, I would at least document it in the DT
> > bindings. It will be a good occasion to switch the bindings to YAML ;-)
>
> Interesting that you bring this up. Conversion to yaml is sitting
> waiting to land (or additional review comments):
>
> https:
On Fri, May 01, 2020 at 10:28:55PM +0200, Peter Zijlstra wrote:
> +++ b/include/linux/static_call_types.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _STATIC_CALL_TYPES_H
> +#define _STATIC_CALL_TYPES_H
> +
> +#include
> +
> +#define STATIC_CALL_PREFIX __SC__
From: Ashish Kalra
The guest support for detecting and enabling SEV Live migration
feature uses the following logic :
- kvm_init_plaform() checks if its booted under the EFI
- If not EFI,
i) check for the KVM_FEATURE_CPUID
ii) if CPUID reports that migration is support then issu
From: Ashish Kalra
Introduce a new AMD Memory Encryption GUID which is currently
used for defining a new UEFI enviroment variable which indicates
UEFI/OVMF support for the SEV live migration feature. This variable
is setup when UEFI/OVMF detects host/hypervisor support for SEV
live migration and
On Tue, May 05, 2020 at 02:13:01PM -0700, a...@linux-foundation.org wrote:
>
> The patch titled
> Subject: arch/x86/Makefile: use $(CONFIG_SHELL)
> has been added to the -mm tree. Its filename is
> arch-x86-makefile-use-config_shell.patch
>
> This patch should soon appear at
>
> h
From: Ashish Kalra
Add new KVM_FEATURE_SEV_LIVE_MIGRATION feature for guest to check
for host-side support for SEV live migration. Also add a new custom
MSR_KVM_SEV_LIVE_MIG_EN for guest to enable the SEV live migration
feature.
Signed-off-by: Ashish Kalra
---
Documentation/virt/kvm/cpuid.rst
From: Ashish Kalra
Add support for static allocation of the unified Page encryption bitmap by
extending kvm_arch_commit_memory_region() callack to add svm specific x86_ops
which can read the userspace provided memory region/memslots and calculate
the amount of guest RAM managed by the KVM and gro
From: Brijesh Singh
Invoke a hypercall when a memory region is changed from encrypted ->
decrypted and vice versa. Hypervisor needs to know the page encryption
status during the guest migration.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc
From: Brijesh Singh
The ioctl can be used to retrieve page encryption bitmap for a given
gfn range.
Return the correct bitmap as per the number of pages being requested
by the user. Ensure that we only copy bmap->num_pages bytes in the
userspace buffer, if bmap->num_pages is not byte aligned we
From: Brijesh Singh
This hypercall is used by the SEV guest to notify a change in the page
encryption status to the hypervisor. The hypercall should be invoked
only when the encryption attribute is changed from encrypted -> decrypted
and vice versa. By default all guest pages are considered encry
From: Brijesh Singh
The ioctl can be used to set page encryption bitmap for an
incoming guest.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
From: Brijesh Singh
KVM hypercall framework relies on alternative framework to patch the
VMCALL -> VMMCALL on AMD platform. If a hypercall is made before
apply_alternative() is called then it defaults to VMCALL. The approach
works fine on non SEV guest. A VMCALL would causes #UD, and hypervisor
w
From: Brijesh Singh
The command finalize the guest receiving process and make the SEV guest
ready for the execution.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc:
On Tue, May 5, 2020 at 1:42 PM Tony Lindgren wrote:
>
> * Adam Ford [200504 16:02]:
> > Various OMAP3 boards have two AES blocks, but only one is currently
> > available, because the hwmods are only configured for one.
> >
> > This patch migrates the hwmods for the AES engine to sysc-omap2
> > wh
From: Brijesh Singh
The command is used for copying the incoming buffer into the
SEV guest memory space.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.k
On Mon, May 04 2020 at 22:39:35 +0300, Pavel Begunkov quoth thus:
> do_splice() is used by io_uring, as will be do_tee(). Move f_mode
> checks from sys_{splice,tee}() to do_{splice,tee}(), so they're
> enforced for io_uring as well.
I'm not seeing any check against splicing a pipe to itself in th
From: Brijesh Singh
The command is used to create the encryption context for an incoming
SEV guest. The encryption context can be later used by the hypervisor
to import the incoming data into the SEV guest memory space.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzin
From: Brijesh Singh
The command is used for encrypting the guest memory region using the encryption
context created with KVM_SEV_SEND_START.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
From: Brijesh Singh
The command is used to finailize the encryption context created with
KVM_SEV_SEND_START command.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc:
From: Brijesh Singh
The command is used to create an outgoing SEV guest encryption context.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc:
Hi Doug,
On Tue, May 05, 2020 at 02:12:20PM -0700, Doug Anderson wrote:
> On Tue, May 5, 2020 at 2:06 PM Laurent Pinchart wrote:
> > On Tue, May 05, 2020 at 10:59:30AM -0700, Doug Anderson wrote:
> >> On Tue, May 5, 2020 at 1:24 AM Laurent Pinchart wrote:
> >>> On Mon, May 04, 2020 at 09:36:31PM -
From: Ashish Kalra
The series add support for AMD SEV guest live migration commands. To protect the
confidentiality of an SEV protected guest memory while in transit we need to
use the SEV commands defined in SEV API spec [1].
SEV guest VMs have the concept of private and shared memory. Private
Hi,
On Tue, May 5, 2020 at 2:06 PM Laurent Pinchart
wrote:
>
> Hi Doug,
>
> On Tue, May 05, 2020 at 10:59:30AM -0700, Doug Anderson wrote:
> > On Tue, May 5, 2020 at 1:24 AM Laurent Pinchart wrote:
> > > On Mon, May 04, 2020 at 09:36:31PM -0700, Douglas Anderson wrote:
> > > > The ti-sn65dsi86 MI
Hello,
On Tue, May 05, 2020 at 05:01:18PM -0400, J. Bruce Fields wrote:
> On Mon, May 04, 2020 at 10:15:14PM -0400, J. Bruce Fields wrote:
> > Though now I'm feeling greedy: it would be nice to have both some kind
> > of global flag, *and* keep kthread->data pointing to svc_rqst (as that
> > would
301 - 400 of 1621 matches
Mail list logo
