On Wed, Feb 10, 2021 at 12:59:59PM -0700, Jens Axboe wrote:
> On 2/10/21 12:33 PM, Mike Snitzer wrote:
> > On Mon, Feb 01 2021 at 12:10am -0500,
> > Satya Tangirala wrote:
> >
> >> This patch series adds support for inline encryption to the device mapper.
> >>
> >> Patch 1 introduces the "passthr
Hi Vincenzo,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20210211]
[cannot apply to arm64/for-next/core xlnx/master arm/for-next soc/for-next
kvmarm/next linus/master hnaz-linux-mm/master v5.11-rc7 v5.11-rc6 v5.11-rc5
v5.11-rc7]
[If your patch is applied to the
Hi Linus,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 291009f656e8eaebbdfd3a8d99f6b190a9ce9deb
commit: e1c6edcbea13de025c3406645b4cce4ac3baf973 leds: rt8515: Add Richtek
RT8515 LED driver
date: 12 days ago
con
On Thu, Feb 11 2021 at 6:01pm -0500,
Satya Tangirala wrote:
> On Wed, Feb 10, 2021 at 12:59:59PM -0700, Jens Axboe wrote:
> > On 2/10/21 12:33 PM, Mike Snitzer wrote:
> > > On Mon, Feb 01 2021 at 12:10am -0500,
> > > Satya Tangirala wrote:
> > >
> > >> This patch series adds support for inline
On Mon, 1 Feb 2021, Thomas Gleixner wrote:
> >> While it cures the problem on the reporters machine it breaks machines
> >> with Intel chipsets which use bit 0-5 of the D register. So check only
> >> for bit 6 being 0 which is the case on these Intel machines as well.
> >
> > This looks fine, but
On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote:
> On 11.02.21 12:27, Mike Rapoport wrote:
> > On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote:
>
> So let's talk about the main user-visible differences to other memfd files
> (especially, other purely virtual fil
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Thu, 11 Feb 2021 21:28:20 +0530 you wrote:
> The current admin function (AF) driver and the netdev driver supports
> OcteonTx2 silicon variants. The same OcteonTx2's
> Resource Virtualization Unit (RVU) is carried forwa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull one final powerpc fix for 5.11:
The following changes since commit 24321ac668e452a4942598533d267805f291fdc9:
powerpc/64/signal: Fix regression in __kernel_sigtramp_rt64() semantics
(2021-02-02 22:14:41 +1100)
are availabl
Hi,
Thanks for your review.
2021年2月1日(月) 19:08 Michal Simek :
>
> Hi,
>
> On 1/31/21 3:30 PM, Nobuhiro Iwamatsu wrote:
> > zynqmp_pm_get_eemi_ops() was removed in commit 4db8180ffe7c: "Firmware:
> > xilinx:
> > Remove eemi ops for fpga related APIs", but not in
> > IS_REACHABLE(CONFIG_ZYNQMP_FI
From: "Melanie Plageman (Microsoft)"
Add ability to set the number of hardware queues with new module parameter,
storvsc_max_hw_queues. The default value remains the number of CPUs. This
functionality is useful in some environments (e.g. Microsoft Azure) where
decreasing the number of hardware q
Linus Torvalds wrote:
> Also, honestly, I really *REALLY* want your commit messages to talk
> about who has been cc'd, who has been part of development, and point
> to the PUBLIC MAILING LISTS WHERE THAT DISCUSSION WAS TAKING PLACE, so
> that I can actually see that "yes, other people were involv
f
> generic memory_model.h for !DISCONTIGMEM
> date: 8 weeks ago
> config: m68k-randconfig-r021-20210211 (attached as .config)
> compiler: m68k-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/
zynqmp_pm_get_eemi_ops() was removed in commit 4db8180ffe7c: "Firmware: xilinx:
Remove eemi ops for fpga related APIs", but not in
IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE).
Any driver who want to communicate with PMC using EEMI APIs use the functions
provided
for each function.
This removed zynqmp_pm
On Thu, 2021-02-11 at 17:13 -0500, Stefan Berger wrote:
> On 2/11/21 2:54 PM, Nayna Jain wrote:
> > Certificates being loaded onto the IMA trusted keyring must be signed by
> > a key on either the builtin and secondary trusted keyring.
> >
> > This patch creates and includes in the kernel image an
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 291009f656e8eaebbdfd3a8d99f6b190a9ce9deb
commit: 808b49da54e640cba5c5c92dee658018a529226b alpha: turn
csum_partial_copy_from_user() into csum_and_copy_from_user()
date: 9 months ago
config: alpha-defconfig
of_dev_get() and of_dev_put are just wrappers for get_device()/put_device()
on a platform_device. There's also already platform_device_{get,put}()
wrappers for this purpose. Let's update the few users and remove
of_dev_{get,put}().
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerr
of_device_node_put() is just a wrapper for of_node_put(). The platform
driver core is already polluted with of_node pointers and the only 'get'
already uses of_node_get() (though typically the get would happen in
of_device_alloc()).
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Frank Rowand
On Wednesday 10 February 2021 16:09:43 kos...@marvell.com wrote:
> From: Grzegorz Jaszczyk
>
> Add "phys" entries pointing to COMPHYs to PCIe and USB3 nodes
>
> Signed-off-by: Grzegorz Jaszczyk
> Signed-off-by: Konstantin Porotchkin
Hello! This patch is not needed and now does nothing.
> ---
This is a couple of cleanups for of_device.h. They fell out from my
attempt at decoupling of_device.h and of_platform.h which is a mess
and I haven't finished, but there's no reason to wait on these.
Rob
Rob Herring (2):
of: Remove of_dev_{get,put}()
driver core: platform: Drop of_device_node
On Wednesday 10 February 2021 16:09:42 kos...@marvell.com wrote:
> From: Grzegorz Jaszczyk
>
> Adding phy description to pcie, sata and usb will allow appropriate drivers
> to configure marvell comphy-a3700 accordingly.
>
> Signed-off-by: Grzegorz Jaszczyk
> Signed-off-by: Konstantin Porotchkin
On Wed, Feb 10, 2021 at 10:23:58PM -0500, Rodrigo Vivi wrote:
> On Tue, Feb 09, 2021 at 04:28:31PM -0500, Lyude Paul wrote:
> > Apparently the new gen9_bc platforms that Intel has introduced don't
> > provide us with a STRAP config register to read from for initializing DDI
> > B, C, and D detectio
On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote:
> Hi Jarkko,
>
> On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen wrote:
> >
> > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> > >
> > >
> > > On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> > > > On Thu, Jan 21, 2021 at
On Fri, Feb 12, 2021 at 01:34:31AM +0200, Jarkko Sakkinen wrote:
> On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote:
> > Hi Jarkko,
> >
> > On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen wrote:
> > >
> > > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> > > >
> > > >
Verify that user applications are not using the kernel RPC message
handle to restrict them from directly attaching to guest OS on the
remote subsystem. This is a port of CVE-2019-2308 fix.
Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
Cc: Srinivas Kandagatla
Cc: Jon
Hi all,
Today's linux-next merge of the btrfs tree got a conflict in:
lib/iov_iter.c
between commit:
11432a3cc061 ("iov_iter: Add ITER_XARRAY")
from the fscache tree and commit:
325a835476e3 ("iov_iter: Remove memzero_page() in favor of zero_user()")
from the btrfs tree.
I fixed it up
On 2/11/21 3:37 PM, Dmitry Baryshkov wrote:
> Verify that user applications are not using the kernel RPC message
> handle to restrict them from directly attaching to guest OS on the
> remote subsystem. This is a port of CVE-2019-2308 fix.
>
> Fixes: c68cfb718c8f ("misc: fastrpc: Add support for co
On 2/11/21 12:47 PM, Zi Yan wrote:
> On 28 Jan 2021, at 16:53, Mike Kravetz wrote:
>
>> On 1/28/21 10:26 AM, Joao Martins wrote:
>>> For a given hugepage backing a VA, there's a rather ineficient
>>> loop which is solely responsible for storing subpages in GUP
>>> @pages/@vmas array. For each subp
Hi Sameer
> diff --git a/sound/soc/generic/simple-card-utils.c
> b/sound/soc/generic/simple-card-utils.c
> index bc0b62e..0754d70 100644
> --- a/sound/soc/generic/simple-card-utils.c
> +++ b/sound/soc/generic/simple-card-utils.c
> @@ -173,16 +173,15 @@ int asoc_simple_parse_clk(struct device *d
On Thursday 11 February 2021 12:22:52 nnet wrote:
> On Thu, Feb 11, 2021, at 11:55 AM, Pali Rohár wrote:
> > On Wednesday 10 February 2021 11:08:59 nnet wrote:
> > > On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote:
> > > > > > Hello! Could you please enable userspace governor during kernel
> >
The state of the remote processor may have changed between the
time a call to rproc_shutdown() was made and the time it is
executed. To avoid moving forward with an operation that may
have been cancelled, recheck while holding the mutex.
Cc:
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Following the work done here [1], this set provides support for the
remoteproc core to release resources associated with a remote processor
without having to switch it off. That way a platform driver can be removed
or the application processor power cycled while the remote processor is
still operat
Rename function rproc_actuate() to rproc_attach(). That way it is
easy to understand that it does the opposite of rproc_detach().
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 8
1 file changed, 4 inserti
Add a new get_loaded_rsc_table() operation in order to support
scenarios where the remoteproc core has booted a remote processor
and detaches from it. When re-attaching to the remote processor,
the core needs to know where the resource table has been placed
in memory.
Signed-off-by: Mathieu Poiri
This patch adds a binding to guide the remoteproc core on how to deal with
remote processors in two cases:
1) When an application holding a reference to a remote processor character
device interface crashes.
2) when the platform driver for a remote processor is removed.
In both cases if "auto
There is a need to know when a remote processor has been attached
to rather than booted by the remoteproc core. In order to avoid
manipulating two variables, i.e rproc::autonomous and
rproc::state, get rid of the former and simply use the newly
introduced RPROC_ATTACHED state.
Signed-off-by: Math
Whether started at probe() time or thereafter from the command
line, a remote processor needs to be shutdown before the final
cleanup phases can happen. Otherwise the system may be left in
an unpredictable state where the remote processor is expecting
the remoteproc core to be providing services w
Add a new RPROC_ATTACHED state to take into account scenarios
where the remoteproc core needs to attach to a remote processor
that is booted by another entity.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_sysfs.c | 1 +
in
Move the setting of the resource table installed by an external
entity to rproc_ops::get_loaded_rsc_table(). This is to support
scenarios where a remote processor has been started by the core
but is detached at a later stage. To re-attach the remote
processor, the address of the resource table ne
From: Arnaud POULIQUEN
Some actions such as memory resources reallocation are needed when
trying to reattach a co-processor. Use the prepare() operation for
these actions.
Co-developed-by: Mathieu Poirier
Signed-off-by: Mathieu Poirier
Signed-off-by: Arnaud POULIQUEN
---
drivers/remoteproc/r
Add an new detach() operation in order to support scenarios where
the remoteproc core is going away but the remote processor is
kept operating. This could be the case when the system is
rebooted or when the platform driver is removed.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewe
Introduce function __rproc_detach() to perform the same kind of
operation as rproc_stop(), but instead of switching off the
remote processor using rproc->ops->stop(), it uses
rproc->ops->detach(). That way it is possible for the core
to release the resources associated with a remote processor whil
Introduce function rproc_detach() to enable the remoteproc
core to release the resources associated with a remote processor
without stopping its operation.
Signed-off-by: Mathieu Poirier
---
New for V5:
- Fixed comment about rproc_actuate() that no longer exists.
- Added call to rproc_unprepare_d
Add a return value to function rproc_shutdown() in order to
properly deal with error conditions that may occur.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 19 ++-
include/linux/remoteproc.h
This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.
As with the "running" case, the command can't be carried out if the
remote processor is already in operation.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Poul
This patch introduces the capability to stop a remote processor
that has been attached to by the remoteproc core. For that to
happen a rproc::ops::stop() operation need to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/r
Refactor function rproc_del() and rproc_cdev_release() to take
into account the policy specified in the device tree.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_cdev.c | 18 +++---
drivers/remoteproc/remoteproc_core.c | 36 +
This patch introduces the capability to detach a remote processor
that has been attached to or booted by the remoteproc core. For
that to happen a rproc::ops::detach() operation need to be
available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
driver
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+
If it is possible to detach the remote processor, keep an untouched
copy of the resource table. That way we can start from the same
resource table without having to worry about original values or what
elements the startup code has changed when re-attaching to the remote
processor.
Reported-by: Ar
The pull request you sent on Fri, 12 Feb 2021 10:15:59 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-5.11-8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dcc0b49040c70ad827a7f3d58a21b01fdb14e749
Thank you!
--
Deet-doot-d
Em Thu, Feb 11, 2021 at 06:14:03PM +0900, Namhyung Kim escreveu:
> Hello,
>
> On Tue, Feb 9, 2021 at 11:51 PM Dmitry Safonov wrote:
> >
> > GCC (GCC) 8.4.0 20200304 fails to build perf with:
> > : util/symbol.c: In function 'dso__load_bfd_symbols':
> > : util/symbol.c:1626:16: error: comparison o
On Wed, Dec 30, 2020 at 11:36:45AM -0600, David Lechner wrote:
> On 12/25/20 6:15 PM, William Breathitt Gray wrote:
>
> > diff --git a/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
> > b/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
> > index eac32180c40d..0ecba24d43aa 100644
>
On Wed, 10 Feb 2021 16:33:07 -0800 Ira Weiny wrote:
> > Signed-off-by: Ira Weiny
>
> This already has my signed off by so I'm not going to 'review'. With Prathu's
> testing information I hope this can land.
>
> Andrew did you see this patch?
I did now ;)
Tossed onto the post-rc1 pile, thank
On Thu, 11 Feb 2021, Song Bao Hua (Barry Song) wrote:
>
> Actually in m68k, I also saw its IRQ entry disabled interrupts by
> ' move#0x2700,%sr /* disable intrs */'
>
> arch/m68k/include/asm/entry.h:
>
> .macro SAVE_ALL_SYS
> move#0x2700,%sr /* disabl
On Thu, 11 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > > > On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > > >
> > > > > TBH, that is why m68k is so confusing. irqs_disabled() on m68k
> > > > > should just reflect the sta
On 2/10/21 1:21 PM, Axel Rasmussen wrote:
> From: Peter Xu
>
> It is a preparation work to be able to behave differently in the per
> architecture huge_pte_alloc() according to different VMA attributes.
>
> Pass it deeper into huge_pmd_share() so that we can avoid the find_vma() call.
>
> Sugge
> -Original Message-
> From: Finn Thain [mailto:fth...@telegraphics.com.au]
> Sent: Friday, February 12, 2021 12:57 PM
> To: Song Bao Hua (Barry Song)
> Cc: tanxiaofei ; j...@linux.ibm.com;
> martin.peter...@oracle.com; linux-s...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux..
On Fri, 12 Feb 2021, Song Bao Hua (Barry Song) wrote:
>
> > -Original Message-
> > From: Finn Thain [mailto:fth...@telegraphics.com.au]
> > Sent: Friday, February 12, 2021 12:57 PM
> > To: Song Bao Hua (Barry Song)
> > Cc: tanxiaofei ; j...@linux.ibm.com;
> > martin.peter...@oracle.com;
-20210211]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Sascha-Hauer/quota-Add-mountpath-based-quo
On Thursday, February 11, 2021 7:18:26 PM MSK you wrote:
> From: Sven Van Asbroeck
>
> The buffers in the lan743x driver's receive ring are always 9K,
> even when the largest packet that can be received (the mtu) is
> much smaller. This performs particularly badly on cpu archs
> without dma cache
From: Todd Sabin
Linux network stack uses an allocation page cache for skbs. The
purpose is to reduce the number of page allocations that it needs to
make, and it works by allocating a group of pages, and then
sub-allocating skb memory from them. When all skbs referencing the
shared pages are f
On Tue, 9 Feb 2021 10:26:21 + (UTC), Christophe Leroy wrote:
> get_tbl() is confusing as it returns the content TBL register
> on PPC32 but the concatenation of TBL and TBU on PPC64.
>
> Use mftb() instead.
>
> This will allow the removal of get_tbl() in a following patch.
Applied to powerpc
On Tue, 9 Feb 2021 19:29:26 + (UTC), Christophe Leroy wrote:
> This series implements C syscall entry/exit for PPC32. It reuses
> the work already done for PPC64.
>
> This series is based on today's next-test (f538b53fd47a) where main patchs
> from v5 are merged in.
>
> The first patch is im
On Mon, 8 Feb 2021 07:17:40 + (UTC), Christophe Leroy wrote:
> THREAD_ALIGN_SHIFT = THREAD_SHIFT + 1 = PAGE_SHIFT + 1
> Maximum PAGE_SHIFT is 18 for 256k pages so
> THREAD_ALIGN_SHIFT is 19 at the maximum.
>
> No need to clobber cr1, it can be preserved when moving r1
> into CR when we check s
On Tue, 9 Feb 2021 14:02:12 + (UTC), Christophe Leroy wrote:
> Copied from commit 4b842e4e25b1 ("x86: get rid of small
> constant size cases in raw_copy_{to,from}_user()")
>
> Very few call sites where that would be triggered remain, and none
> of those is anywhere near hot enough to bother.
On Mon, 8 Feb 2021 15:10:19 + (UTC), Christophe Leroy wrote:
> This series implements C syscall entry/exit for PPC32. It reuses
> the work already done for PPC64.
>
> This series is based on today's merge-test
> (b6f72fc05389e3fc694bf5a5fa1bbd33f61879e0)
>
> In terms on performance we have t
On Sun, 7 Feb 2021 14:43:12 +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./arch/powerpc/kvm/book3s_xive.c:1856:2-17: WARNING: Assignment of 0/1
> to bool variable.
>
> ./arch/powerpc/kvm/book3s_xive.c:1854:2-17: WARNING: Assignment of 0/1
> to bool variable.
Applied t
On 2/10/21 1:21 PM, Axel Rasmussen wrote:
> From: Peter Xu
>
> Huge pmd sharing could bring problem to userfaultfd. The thing is that
> userfaultfd is running its logic based on the special bits on page table
> entries, however the huge pmd sharing could potentially share page table
> entries fo
> -Original Message-
> From: Finn Thain [mailto:fth...@telegraphics.com.au]
> Sent: Friday, February 12, 2021 12:58 PM
> To: Song Bao Hua (Barry Song)
> Cc: tanxiaofei ; j...@linux.ibm.com;
> martin.peter...@oracle.com; linux-s...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux...
On Wed, Feb 10, 2021 at 04:23:09PM -0800, Paul E. McKenney wrote:
> On Wed, Feb 10, 2021 at 03:50:07PM -0800, Yury Norov wrote:
> > On Wed, Feb 10, 2021 at 9:57 AM Paul E. McKenney wrote:
> > >
> > > On Wed, Feb 10, 2021 at 06:26:54PM +0200, Andy Shevchenko wrote:
> > > > On Tue, Feb 09, 2021 at 0
Hi Sergej, thank you for testing this !
On Thu, Feb 11, 2021 at 7:18 PM Sergej Bauer wrote:
>
> although whole set of tests might be an overly extensive, but after applying
> patch v2 [1/5]
> tests are:
I am unfamiliar with the test_ber tool. Does this patch improve things?
When a CPU offlined and onlined via device_offline() and device_online()
the userspace gets uevent notification. If, after receiving "online" uevent,
userspace executes sched_setaffinity() on some task trying to move it
to a recently onlined CPU, then it often fails with -EINVAL. Userspace needs
to
Hi,
Thanks for your comment.
On Thu, Feb 11, 2021 at 02:13:07PM -0800, David Miller wrote:
> From: Nobuhiro Iwamatsu
> Date: Thu, 11 Feb 2021 01:29:52 +0900
>
> > +static int visconti_eth_init_hw(struct platform_device *pdev, struct
> > plat_stmmacenet_data *plat_dat)
> > +{
> > + struct vis
Fix an INVPCID bug on SVM where it fails to injected a #UD when INVPCID is
supported but not exposed to the guest. Do a bit of cleanup in patch 02
now that both VMX and SVM support PCID/INVPCID.
Patch 03 address KVM behavior that has long confused the heck out of me.
KVM currently allows enabling
Intercept INVPCID if it's disabled in the guest, even when using NPT,
as KVM needs to inject #UD in this case.
Fixes: 4407a797e941 ("KVM: SVM: Enable INVPCID feature on AMD")
Cc: Babu Moger
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/svm/svm.c | 8
1 file changed, 4 insertions(
Remove the restriction that prevents VMX from exposing INVPCID to the
guest without PCID also being exposed to the guest. The justification of
the restriction is that INVPCID will #UD if it's disabled in the VMCS.
While that is a true statement, it's also true that RDTSCP will #UD if
it's disabled
Advertise INVPCID by default (if supported by the host kernel) instead
of having both SVM and VMX opt in. INVPCID was opt in when it was a
VMX only feature so that KVM wouldn't prematurely advertise support
if/when it showed up in the kernel on AMD hardware.
Signed-off-by: Sean Christopherson
--
Hi Pavel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kselftest/next]
[also build test ERROR on tip/sched/core tip/perf/core linux/master
linus/master v5.11-rc7 next-20210211]
[cannot apply to hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree
On Thu, Feb 11, 2021 at 04:23:39PM -0800, Yury Norov wrote:
> On Wed, Feb 10, 2021 at 04:23:09PM -0800, Paul E. McKenney wrote:
> > On Wed, Feb 10, 2021 at 03:50:07PM -0800, Yury Norov wrote:
> > > On Wed, Feb 10, 2021 at 9:57 AM Paul E. McKenney
> > > wrote:
> > > >
> > > > On Wed, Feb 10, 2021
On Thu, Feb 11, 2021, at 3:44 PM, Pali Rohár wrote:
> On Thursday 11 February 2021 12:22:52 nnet wrote:
> > On Thu, Feb 11, 2021, at 11:55 AM, Pali Rohár wrote:
> > > On Wednesday 10 February 2021 11:08:59 nnet wrote:
> > > > On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote:
> > > > > > > Hel
On Thu, Feb 11, 2021 at 06:04:59PM -0500, Mike Snitzer wrote:
> On Thu, Feb 11 2021 at 6:01pm -0500,
> Satya Tangirala wrote:
>
> > On Wed, Feb 10, 2021 at 12:59:59PM -0700, Jens Axboe wrote:
> > > On 2/10/21 12:33 PM, Mike Snitzer wrote:
> > > > On Mon, Feb 01 2021 at 12:10am -0500,
> > > > Sat
Hi Vincenzo,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20210211]
[cannot apply to arm64/for-next/core xlnx/master arm/for-next soc/for-next
kvmarm/next linus/master hnaz-linux-mm/master v5.11-rc7 v5.11-rc6 v5.11-rc5
v5.11-rc7]
[If your patch is applied to the
On Thu, Feb 11, 2021 at 4:34 PM Sean Christopherson wrote:
>
> Remove the restriction that prevents VMX from exposing INVPCID to the
> guest without PCID also being exposed to the guest. The justification of
> the restriction is that INVPCID will #UD if it's disabled in the VMCS.
> While that is
On Thu, Feb 11, 2021 at 4:34 PM Sean Christopherson wrote:
>
> Intercept INVPCID if it's disabled in the guest, even when using NPT,
> as KVM needs to inject #UD in this case.
>
> Fixes: 4407a797e941 ("KVM: SVM: Enable INVPCID feature on AMD")
> Cc: Babu Moger
> Signed-off-by: Sean Christopherson
On Thu, Feb 11, 2021 at 4:34 PM Sean Christopherson wrote:
>
> Advertise INVPCID by default (if supported by the host kernel) instead
> of having both SVM and VMX opt in. INVPCID was opt in when it was a
> VMX only feature so that KVM wouldn't prematurely advertise support
> if/when it showed up
From: Vladimir Oltean
When a struct switchdev_attr is notified through switchdev, there is no
way to report informational messages, unlike for struct switchdev_obj.
Signed-off-by: Vladimir Oltean
Reviewed-by: Ido Schimmel
---
Changes in v3:
None.
Changes in v2:
Patch is new.
.../ethernet/ma
From: Vladimir Oltean
If for example this command:
ip link set swp0 type bridge_slave flood off mcast_flood off learning off
succeeded at configuring BR_FLOOD and BR_MCAST_FLOOD but not at
BR_LEARNING, there would be no attempt to revert the partial state in
any way. Arguably, if the user chang
From: Vladimir Oltean
For the netlink interface, propagate errors through extack rather than
simply printing them to the console. For the sysfs interface, we still
print to the console, but at least that's one layer higher than in
switchdev, which also allows us to silently ignore the offloading
From: Vladimir Oltean
The initial goal of this series was to have better support for
standalone ports mode on the DSA drivers like ocelot/felix and sja1105.
This turned out to require some API adjustments in both directions:
to the information presented to and by the switchdev notifier, and to
th
From: Vladimir Oltean
For a DSA switch port operating in standalone mode, address learning
doesn't make much sense since that is a bridge function. In fact,
address learning even breaks setups such as this one:
+-+
|
From: Vladimir Oltean
This switchdev attribute offers a counterproductive API for a driver
writer, because although br_switchdev_set_port_flag gets passed a
"flags" and a "mask", those are passed piecemeal to the driver, so while
the PRE_BRIDGE_FLAGS listener knows what changed because it has the
From: Vladimir Oltean
In preparation of offloading the bridge port flags which have
independent settings for unknown multicast and for broadcast, we should
also start reserving one destination Port Group ID for the flooding of
broadcast packets, to allow configuring it individually.
Signed-off-b
From: Vladimir Oltean
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
expressed by the bridge through switchdev, and not all of them can be
emulated by DSA mid-layer API at the same time.
One possible configuration is when the bridge offloads the port flags
using a mask tha
From: Vladimir Oltean
We should not be unconditionally enabling address learning, since doing
that is actively detrimential when a port is standalone and not offloading
a bridge. Namely, if a port in the switch is standalone and others are
offloading the bridge, then we could enter a situation wh
From: Vladimir Oltean
The chip can configure unicast flooding, broadcast flooding and learning.
Learning is per port, while flooding is per {ingress, egress} port pair
and we need to configure the same value for all possible ingress ports
towards the requested one.
While multicast flooding is no
On Fri, Feb 12, 2021 at 10:38:10AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the btrfs tree got a conflict in:
>
> lib/iov_iter.c
>
> between commit:
>
> 11432a3cc061 ("iov_iter: Add ITER_XARRAY")
>
> from the fscache tree and commit:
>
> 325a835476e3 ("io
There's actually a complication that I just noticed and needs to be
addressed. More below.
Lakshmi Ramasubramanian writes:
> From: Rob Herring
>
> Both arm64 and powerpc do essentially the same FDT /chosen setup for
> kexec. The differences are either omissions that arm64 should have
> or ad
On 2/11/21 5:56 PM, William Breathitt Gray wrote:
On Wed, Dec 30, 2020 at 11:36:45AM -0600, David Lechner wrote:
On 12/25/20 6:15 PM, William Breathitt Gray wrote:
diff --git a/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
b/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
inde
On 2/11/21 5:09 PM, Thiago Jung Bauermann wrote:
There's actually a complication that I just noticed and needs to be
addressed. More below.
<...>
+
+/*
+ * of_kexec_alloc_and_setup_fdt - Alloc and setup a new Flattened Device Tree
+ *
+ * @image: kexec image being loaded.
+ * @i
Hi,
I am getting a very long debate with Finn in this thread:
https://lore.kernel.org/lkml/1612697823-8073-1-git-send-email-tanxiao...@huawei.com/
In short, the debate is about if high-priority IRQs (*not NMI*)
are allowed to preempt an running IRQ handler in hardIRQ context.
In my understanding
601 - 700 of 1369 matches
Mail list logo
