On 09.08.2017 19:39, Guenter Roeck wrote:
> On Wed, Aug 09, 2017 at 05:15:46PM +0200, Maciej S. Szmigiero wrote:
(..)
>>
>> Changes from v6: Add __maybe_unused to it87_resume_sio(), move a message
>> about failure to enter Super I/O on resume to this function, make it clear
to in7.
This will make it consistent with a similar message that it printed on
IT8783.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1: Move code of common probe / resume steps to new functions
so we don't need to make large parts of probe function conditional on a
newly added 'resume
(and had it wrong again on resume from S3).
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1: Move code of common probe / resume steps to new functions
so we don't need to make large parts of probe function conditional on a
newly added 'resume' parameter.
Changes from v2: Code move of common
On 26.07.2017 04:17, Guenter Roeck wrote:
On 07/24/2017 12:37 PM, Maciej S. Szmigiero wrote:
After a suspend / resume cycle we possibly need to reapply chip registers
settings that we had set or fixed in a probe path, since they might have
been reset to default values or set incorrectly
is a problem for RSA
implementations that need it to be exactly correct (like AMD CCP).
Signed-off-by: Maciej S. Szmigiero
Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509
certificates")
Cc: sta...@vger.kernel.org
---
This is a resend of a patch that was previously
On 17.04.2018 17:07, Kamil Konieczny wrote:
>
>
> On 17.04.2018 15:39, Maciej S. Szmigiero wrote:
>> The signatureValue field of a X.509 certificate is encoded as a BIT STRING.
>> For RSA signatures this BIT STRING is of so-called primitive subtype, which
>> cont
the leftover file length before passing this value to
verify_patch_size().
Signed-off-by: Maciej S. Szmigiero
Link:
http://lkml.kernel.org/r/b4854b17-e3ba-54d6-488d-0e0bfffe4...@maciej.szmigiero.name
[ Split comment. ]
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/cpu/microcode/amd.c | 15
)
whether the size of a patch is not too large for a particular CPU family.
By adding these checks as separate functions the actual microcode loading
code won't get interspersed with a lot of checks and so will be more
readable.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c
for
printk()-style functions to work.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 45 ++---
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
Currently, it is very easy to make the AMD microcode update driver crash
or spin on a malformed microcode container file since it does very little
consistency checking on data loaded from such file.
This series introduces various checks, mostly on length-type fields,
so all corrupted microcode
Currently, the code scanning the CPU equivalence table read from a
microcode container file assumes that it actually contains a terminating
zero entry.
Let's check also the size of this table to make sure that we don't read
past it in case it actually doesn't.
Signed-off-by: Maciej S. Szmigiero
.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/include/asm/microcode_amd.h | 1 +
arch/x86/kernel/cpu/microcode/amd.c | 4
2 files changed, 5 insertions(+)
diff --git a/arch/x86/include/asm/microcode_amd.h
b/arch/x86/include/asm/microcode_amd.h
index 209492849566..8ea477fbc65f 100644
This commit converts the late loader in the AMD microcode update driver to
use newly introduced microcode container data checking functions as the
previous commit did for the early loader.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 87
On 18.03.2018 17:12, Borislav Petkov wrote:
> On Fri, Mar 16, 2018 at 12:07:42AM +0100, Maciej S. Szmigiero wrote:
>> verify_patch_size() function verifies whether the microcode container file
>> remaining size is large enough to contain a patch of the indicated size.
>>
&g
On 18.04.2018 15:53, Borislav Petkov wrote:
> On Wed, Apr 18, 2018 at 02:39:27PM +0200, Maciej S. Szmigiero wrote:
>> Can't really find this commit in any tree I have looked at (bp.git and
>> tip.git at kernel.org).
>> Was it pushed somewhere else?
>
> No. Still w
is a problem for RSA
implementations that need it to be exactly correct (like AMD CCP).
Signed-off-by: Maciej S. Szmigiero
Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509
certificates")
Cc: sta...@vger.kernel.org
---
This is a resend without changes of a patch that was
On 07.03.2018 16:44, David Howells wrote:
> Maciej S. Szmigiero wrote:
>
>> +if (!strcmp(ctx->cert->sig->pkey_algo, "rsa")) {
>
> I'm going to change this to '== 0' rather than '!'.
No problem.
> David
>
Thanks,
Maciej
On 22.02.2018 21:44, Maciej S. Szmigiero wrote:
> Hi William,
> Hi Linus,
>
> On 22.02.2018 21:30, William Breathitt Gray wrote:
>> On Thu, Feb 22, 2018 at 04:16:17PM +0100, Linus Walleij wrote:
>>> On Fri, Dec 29, 2017 at 9:13 PM, William Breathitt Gray
>>&
This reverts commit 92a8046c9d952a2a7d21dfcd3afadc72a0bc0f72.
Now that the patch series changing ISA_BUS_API dependency to selection
was merged this reversion will do the same for gpio-winbond driver to
make it consistent with other ISA bus gpio drivers.
Signed-off-by: Maciej S. Szmigiero
has been a case when this has happened let's better reject
such oversized input data and log an error message in this case so we know
what is going on.
Signed-off-by: Maciej S. Szmigiero
---
drivers/crypto/ccp/ccp-ops.c | 24
1 file changed, 20 insertions(+), 4 deletions
is a problem for RSA
implementations that need it to be exactly correct (like AMD CCP).
Signed-off-by: Maciej S. Szmigiero
Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509
certificates")
Cc: sta...@vger.kernel.org
---
crypto/asymmetric_keys/x509_cert_parser.c | 9 ++
to CCP even
for smaller key sizes and then in a buffer overflow when ccp_run_rsa_cmd()
tried to copy this large input buffer into a RSA key length-sized hardware
input buffer.
Signed-off-by: Maciej S. Szmigiero
Fixes: ceeec0afd684 ("crypto: ccp - Add support for RSA on the CCP"
On 02.03.2018 17:44, Herbert Xu wrote:
> On Sat, Feb 24, 2018 at 05:03:21PM +0100, Maciej S. Szmigiero wrote:
>> rsa-pkcs1pad uses a value returned from a RSA implementation max_size
>> callback as a size of an input buffer passed to the RSA implementation for
>> encryp
On 03.03.2018 00:49, Hook, Gary wrote:
> On 3/2/2018 5:15 PM, Maciej S. Szmigiero wrote:
>> On 02.03.2018 17:44, Herbert Xu wrote:
>>> On Sat, Feb 24, 2018 at 05:03:21PM +0100, Maciej S. Szmigiero wrote:
>>>> rsa-pkcs1pad uses a value returned from a RSA impleme
On 12.02.2018 13:56, Takashi Iwai wrote:
> On Sat, 27 Jan 2018 15:42:59 +0100,
> Maciej S. Szmigiero wrote:
>>
>> The Audigy 2 CA0102 chip (but most likely others from the emu10k1 family,
>> too) has a problem that from time to time it likes to do few DMA reads a
On 12.02.2018 13:44, Takashi Iwai wrote:
> On Sat, 27 Jan 2018 15:42:47 +0100,
> Maciej S. Szmigiero wrote:
>>
>> Commit a5003fc04113 ("[ALSA] emu10k1 - simplify page allocation for synth")
>> switched from using the DMA allocator for synth DMA pages
On 13.02.2018 06:00, Takashi Iwai wrote:
> On Mon, 12 Feb 2018 23:13:13 +0100,
> Maciej S. Szmigiero wrote:
>>
>> On 12.02.2018 13:56, Takashi Iwai wrote:
>>> On Sat, 27 Jan 2018 15:42:59 +0100,
>>> Maciej S. Szmigiero wrote:
>>>>
>>&g
We have been calling dma_set_mask() and then dma_set_coherent_mask() with
the same value, but there is a dma_set_mask_and_coherent() function that
does exactly that so let's use it instead.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1, v2: None in this patch.
sound/pci/emu10k1
to remove the reserved_page allocation is a
trivial change to the page allocation logic to ignore the first page entry
and start its allocations from the second entry (index 1).
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1, v2: None in this patch.
include/sound/emu10k1.h | 1 -
as the CPU physical address space
which is not true for a system with a IOMMU.
Since this made the synth part of the driver non-functional on such systems
let's effectively revert that commit (while keeping the
__synth_free_pages() simplification).
Signed-off-by: Maciej S. Szmigiero
---
Changes fro
printouts are only enabled on an explicit request via the
kernel dynamic debug mechanism.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1: Fix a sparse warning by changing a variable type in
__{get,set}_ptb_entry from u32 to __le32, don't open code EMUPAGESIZE.
Changes from v2: None
it looks like the device tries to accesses up to 256 extra
bytes.
As a workaround let's widen these DMA allocations by an extra page if we
detect that the device is behind a non-passthrough IOMMU (the DMA memory
should be relatively plenty on IOMMU systems).
Signed-off-by: Maciej S. Szmigiero
On 11.01.2018 07:43, Nicolin Chen wrote:
> Checking TE and RE bits in SCR register doesn't work for AC97 mode
> which enables SSIEN, TE and RE in the fsl_ssi_setup_ac97() that's
> called during probe().
>
> So when running into the trigger(), it will always get the result
> of both TE and RE
On 11.01.2018 07:43, Nicolin Chen wrote:
> The define of fsl_ssi_disable_val is not so clear as it mixes two
> steps of calculations together. And those parameter names are also
> a bit long to read.
>
> Since it just tries to exclude the shared bits from the regvals of
> current stream while the
On 11.01.2018 07:43, Nicolin Chen wrote:
> The trigger() calls fsl_ssi_tx_config() and fsl_ssi_rx_config(),
> and both of them jump to fsl_ssi_config(). And fsl_ssi_config()
> later calls another fsl_ssi_rxtx_config().
>
> However, the whole routine, especially fsl_ssi_config() function,
> is too
On 11.01.2018 07:43, Nicolin Chen wrote:
> The _fsl_ssi_set_dai_fmt() is a helper function being called from
> fsl_ssi_set_dai_fmt() as an ASoC operation and fsl_ssi_hw_init()
> mainly for AC97 format initialization.
>
> This patch cleans the _fsl_ssi_set_dai_fmt() in following ways:
> * Removing
On 11.01.2018 07:43, Nicolin Chen wrote:
> The cpu_dai_drv is only used for symmetric_rates. So this patch replaces
> it with a synchronous boolean flag.
You make cpu_dai_drv common to all SSI instances instead of per-instance.
What if you have multiple SSIs in the system with different
Hi all,
On 31.01.2018 03:22, William Breathitt Gray wrote:
> On Tue, Jan 02, 2018 at 10:29:30AM +0100, Linus Walleij wrote:
>> On Fri, Dec 29, 2017 at 9:13 PM, William Breathitt Gray
>> wrote:
>>
>>> Linus, please pickup this entire patchset through your GPIO subsystem
>>> tree; a recursive
On 29.12.2017 17:09, William Breathitt Gray wrote:
> On Fri, Dec 29, 2017 at 12:27:12PM +0200, Andy Shevchenko wrote:
>> On Fri, 2017-12-29 at 00:44 +0100, Maciej S. Szmigiero wrote:
>>> On 28.12.2017 16:12, Andy Shevchenko wrote:
>>>> On Fri, 2017-12-22 at 19:58 +0
On 29.12.2017 11:27, Andy Shevchenko wrote:
> On Fri, 2017-12-29 at 00:44 +0100, Maciej S. Szmigiero wrote:
>> On 28.12.2017 16:12, Andy Shevchenko wrote:
>>> On Fri, 2017-12-22 at 19:58 +0100, Maciej S. Szmigiero wrote:
>>>>
>
>>>> +You w
r I/O chip.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1:
* Added SPDX license tag,
* Removed gpiobase parameter,
* Changed uint{8,16}_t types to u{8,16},
* Added kerneldoc descriptions of driver structures,
* Reformatted winbond_gpio_infos array fields so they are on separate
lines,
*
On 19.12.2017 18:00, Nicolin Chen wrote:
> AC97 configures some registers earlier to start a communication
> with CODECs, so this patch moves those register settings to the
> dai_probe() as well, along with other register configurations.
>
> It also applies _fsl_ssi_set_dai_fmt() to AC97 only
On 19.12.2017 18:00, Nicolin Chen wrote:
> This patch replaces the register read with ssi->i2s_net for
> simplification. It also removes masking SSIEN from scr value
> since it's handled later by regmap_update_bits() to set this
> scr value back.
>
> Signed-off-by: Nicolin Chen
> ---
>
On 19.12.2017 18:00, Nicolin Chen wrote:
> The trigger() calls fsl_ssi_tx_config() and fsl_ssi_rx_config(),
> and both of them jump to fsl_ssi_config(). And fsl_ssi_config()
> later calls another fsl_ssi_rxtx_config().
>
> However, the whole routine, especially fsl_ssi_config() function,
> is too
On 19.12.2017 18:00, Nicolin Chen wrote:
> The define of fsl_ssi_disable_val is not so clear as it mixes two
> steps of calculations together. And those parameter names are also
> a bit long to read.
>
> Since it just tries to exclude the shared bits from the regvals of
> current stream while the
(and had it wrong again on resume from S3).
Signed-off-by: Maciej S. Szmigiero
---
drivers/hwmon/it87.c | 148 ++-
1 file changed, 112 insertions(+), 36 deletions(-)
diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
index 4dfc7238313e
On 23.07.2017 22:01, Guenter Roeck wrote:
> On 07/23/2017 09:12 AM, Maciej S. Szmigiero wrote:
>> After a suspend / resume cycle we possibly need to reapply chip registers
>> settings that we had set or fixed in a probe path, since they might have
>> been reset to default valu
On 21.11.2017 02:14, Nicolin Chen wrote:
> On Tue, Nov 21, 2017 at 01:32:09AM +0100, Maciej S. Szmigiero wrote:
>> On 21.11.2017 01:00, Nicolin Chen wrote:
>>> On Mon, Nov 20, 2017 at 11:13:45PM +0100, Maciej S. Szmigiero wrote:
>> (..)
>>>> We need to make sur
On 21.11.2017 02:52, Nicolin Chen wrote:
> On Mon, Nov 20, 2017 at 11:16:07PM +0100, Maciej S. Szmigiero wrote:
(..)
>> static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
>> @@ -1287,16 +1295,18 @@ static unsigned short fsl_ssi_ac97_read(struct
>> snd_ac97 *ac97,
enabled
mean ruined playback let's play safe here and make sure that no extra
slots are enabled in SACCST every time a playback is started.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1: Split out this part from
"fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode&qu
S. Szmigiero
---
Changes from v1: The SACCST setup code was split out into a separate
commit.
sound/soc/fsl/fsl_ssi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 375aaaf6080d..70df6bf832df 100644
--- a/sound/soc/fsl/fsl_ssi.c
This format is similar to existing SNDRV_PCM_FORMAT_{S,U}20_3 that keep
20-bit PCM samples in 3 bytes, however i.MX6 platform SSI FIFO does not
allow 3-byte accesses (including DMA) so a 4-byte format is needed for it.
Signed-off-by: Maciej S. Szmigiero
---
include/sound/pcm.h | 8
e so allow this, too.
Signed-off-by: Maciej S. Szmigiero
---
sound/soc/fsl/fsl_ssi.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 20ef09e1a395..2aed089fdd76 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sou
On 23.11.2017 00:27, Takashi Sakamoto wrote:
> On Nov 23 2017 04:17, Maciej S. Szmigiero wrote:
(..)
>> --- a/include/uapi/sound/asound.h
>> +++ b/include/uapi/sound/asound.h
>> @@ -236,7 +236,11 @@ typedef int __bitwise snd_pcm_format_t;
>> #define SNDRV_PCM_FOR
On 23.11.2017 09:08, Takashi Iwai wrote:
> On Wed, 22 Nov 2017 20:17:34 +0100,
> Maciej S. Szmigiero wrote:
>>
>> This format is similar to existing SNDRV_PCM_FORMAT_{S,U}20_3 that keep
>> 20-bit PCM samples in 3 bytes, however i.MX6 platform SSI FIFO does not
>> al
On 23.11.2017 08:40, Takashi Sakamoto wrote:
> On Nov 23 2017 08:44, Maciej S. Szmigiero wrote:
>> On 23.11.2017 00:27, Takashi Sakamoto wrote:
>>> On Nov 23 2017 04:17, Maciej S. Szmigiero wrote:
>> (..)
>>>> --- a/include/uapi/sound/asound.h
>>>>
Hi Nicolin,
On 30.11.2017 08:23, Nicolin Chen wrote:
> Hi Maciej,
>
> On Mon, Nov 27, 2017 at 11:34:44PM +0100, Maciej S. Szmigiero wrote:
>> There is no problem in using different bit widths in playback and capture
>> in AC'97 mode so allow this, too.
>
>> @@ -
On 01.12.2017 00:53, Nicolin Chen wrote:
> On Thu, Nov 30, 2017 at 08:20:08PM +0100, Maciej S. Szmigiero wrote:
>
>> In the AC'97 mode we have to differentiate two things:
>> 1) Bit width of the physical AC'97 interface ("AC-link"),
>> 2) Bit width of samples t
On 11.12.2017 16:45, Mauro Carvalho Chehab wrote:
> Em Tue, 10 Oct 2017 23:36:55 +0200
> "Maciej S. Szmigiero" escreveu:
>
>> This patch prepares cxusb driver for supporting the analog part of
>> Medion 95700 (previously only the digital - DVB - mode was supporte
On 20.06.2017 09:09, Oleksij Rempel wrote:
> This node is for Low Power General Purpose Register which can
> be used as Non-Volatile Storage.
>
> Signed-off-by: Oleksij Rempel
> ---
> arch/arm/boot/dts/imx6qdl.dtsi | 4
> arch/arm/boot/dts/imx6ul.dtsi | 4
> 2 files changed, 8
This format is similar to existing SNDRV_PCM_FORMAT_{S,U}20_3 that keep
20-bit PCM samples in 3 bytes, however i.MX6 platform SSI FIFO does not
allow 3-byte accesses (including DMA) so a 4-byte (more conventional)
format is needed for it.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1
e so allow this, too.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1: Adapt format name to changes in the first patch from
this series.
sound/soc/fsl/fsl_ssi.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.
This format is similar to existing SNDRV_PCM_FORMAT_{S,U}20_3 that keep
20-bit PCM samples in 3 bytes, however i.MX6 platform SSI FIFO does not
allow 3-byte accesses (including DMA) so a 4-byte (more conventional)
format is needed for it.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1
e so allow this, too.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1: Adapt format name to changes in the first patch from
this series.
Changes from v2: None.
sound/soc/fsl/fsl_ssi.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_s
Hi,
On 26.11.2017 10:27, Takashi Sakamoto wrote:
> Hi,
>
(..)
> Before applying this patch:
> 166 /* FIXME: the following three formats are not defined properly
> yet */
> 167 [SNDRV_PCM_FORMAT_MPEG] = {
> 168 .le = -1, .signd = -1,
> 169 },
> 170
On 13.12.2017 07:34, Nicolin Chen wrote:
> This patch just simply unifies the coding style.
>
> Signed-off-by: Nicolin Chen
> ---
>
> Changelog
> v1->v2
> * Added two missing indentation changes
> * Removed two extra blank lines.
>
> sound/soc/fsl/fsl_ssi.c | 239
>
On 13.12.2017 07:34, Nicolin Chen wrote:
> This patch refines the comments by:
> 1) Removing all out-of-date comments
> 2) Removing all not-so-useful comments
> 3) Unifying the styles of all comments
> 4) Simplifying over-descriptive comments
> 5) Adding comments to improve code readablity
> 6)
place fsl_ssi_rxtx_reg_val with fsl_ssi_regvals
> ASoC: fsl_ssi: Rename i2smode to i2s_net
> ASoC: fsl_ssi: Define ternary macros to simplify code
>
> sound/soc/fsl/fsl_ssi.c | 1373
> +++--------
> sound/soc/fsl/fsl_ssi.h | 427 --
> sound/soc/fsl/fsl_ssi_dbg.c | 59 +-
> 3 files changed, 876 insertions(+), 983 deletions(-)
>
For the whole series:
Tested-by: Maciej S. Szmigiero
Reviewed-by: Maciej S. Szmigiero
Thanks.
Hi Ignat,
On 13.01.2021 20:17, Ignat Korchagin wrote:
On some specific hardware on early boot we occasionally get
[ 1193.920255][T0] BUG: sleeping function called from invalid context at
mm/mempool.c:381
[ 1193.936616][T0] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid:
0,
Thanks for looking at it Ben.
On 06.01.2021 00:38, Ben Gardon wrote:
(..)
>
> +Sean Christopherson, for whom I used a stale email address.
> .
> I tested this series by running kvm-unit-tests on an Intel Skylake
> machine. It did not introduce any new failures. I also ran the
>
On 06.01.2021 18:28, Ben Gardon wrote:
On Wed, Jan 6, 2021 at 1:26 AM Maciej S. Szmigiero
wrote:
Thanks for looking at it Ben.
On 06.01.2021 00:38, Ben Gardon wrote:
(..)
+Sean Christopherson, for whom I used a stale email address.
.
I tested this series by running kvm-unit-tests
On 06.01.2021 18:56, Ben Gardon wrote:
On Wed, Jan 6, 2021 at 9:37 AM Maciej S. Szmigiero
wrote:
On 06.01.2021 18:28, Ben Gardon wrote:
On Wed, Jan 6, 2021 at 1:26 AM Maciej S. Szmigiero
wrote:
Thanks for looking at it Ben.
On 06.01.2021 00:38, Ben Gardon wrote:
(..)
+Sean
the list_for_each_entry_unsafe macro would not have been appropriate in
this situation because it could keep a reference to the next root across
an MMU lock release + reacquire.
Reported-by: Maciej S. Szmigiero
Suggested-by: Paolo Bonzini
Fixes: faaf05b00aec ("kvm: x86/mmu: Support zapping SPTEs in the TD
time that root could be
freed.
Reported-by: Maciej S. Szmigiero
Suggested-by: Paolo Bonzini
Fixes: faaf05b00aec ("kvm: x86/mmu: Support zapping SPTEs in the TDP MMU")
Fixes: 063afacd8730 ("kvm: x86/mmu: Support invalidate range MMU notifier for TDP
MMU")
Fixes: a6a0b05da9f3 (&q
From: "Maciej S. Szmigiero"
Commit cae7ed3c2cb0 ("KVM: x86: Refactor the MMIO SPTE generation handling")
cleaned up the computation of MMIO generation SPTE masks, however it
introduced a bug how the upper part was encoded:
SPTE bits 52-61 were supposed to contain bits
On 24.12.2020 19:46, Ignat Korchagin wrote:
On Wed, Dec 23, 2020 at 8:57 PM Herbert Xu wrote:
On Wed, Dec 23, 2020 at 04:37:34PM +0100, Maciej S. Szmigiero wrote:
It looks like to me that the skcipher API might not be safe to
call from a softirq context, after all.
skcipher is safe to use
On 14.12.2020 19:11, Maciej S. Szmigiero wrote:
Hi,
I hit a reproducible BUG() when scrubbing a btrfs fs on top of
a dm-crypt device with no_read_workqueue and no_write_workqueue
flags enabled.
Still happens on the current torvalds/master.
Due to this bug it is not possible to use btrfs
On 23.12.2020 22:09, Ignat Korchagin wrote:
(..)
I've been looking into this for the last couple of days because of
other reports [1].
Just finished testing a possible solution. Will submit soon.
Thanks for looking into it.
By the way, on a bare metal I am actually hitting a different problem
Hi,
I am hitting a reproducible BUG() with KVM TDP MMU.
The reproducer based on set_memory_region_test.c from KVM selftests
is available here:
https://gist.github.com/maciejsszmigiero/890218151c242d99f63ea0825334c6c0
The test simply moves a memslot a bit back and forth on the host
while the
Hi,
I hit a reproducible BUG() when scrubbing a btrfs fs on top of
a dm-crypt device with no_read_workqueue and no_write_workqueue
flags enabled.
Steps to reproduce:
1) cryptsetup create -c aes -d /dev/urandom test /dev/vdb1
2) dmsetup table test --showkeys | sed 's/$/ 2 no_read_workqueue
From: "Maciej S. Szmigiero"
Commit cae7ed3c2cb0 ("KVM: x86: Refactor the MMIO SPTE generation handling")
cleaned up the computation of MMIO generation SPTE masks, however it
introduced a bug how the upper part was encoded:
SPTE bits 52-61 were supposed to contain bits
On 06.12.2020 11:09, Paolo Bonzini wrote:
On 05/12/20 01:48, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Commit cae7ed3c2cb0 ("KVM: x86: Refactor the MMIO SPTE generation handling")
cleaned up the computation of MMIO generation SPTE masks, however it
introduced
From: "Maciej S. Szmigiero"
The current memory region move test correctly handles the situation that
the second (realigning) memslot move operation would temporarily trigger
MMIO until it completes, however it does not handle the case in which the
first (misaligning) move oper
Hi Matthias,
On 20.08.2019 21:54, Matthias Schwarzott wrote:
> Hi Maciej,
>
> some comment about wording in commit message and code-comment.
>
> As far as I know the terms are defined like this:
> * gate open = i2c-clients behind gate can be reached
> * gate closed = i2c-clients behind gate are
saa7134_i2c_eeprom_md7134_gate() function and the associated comment uses
an inverted i2c gate open / closed terminology.
Let's fix this.
Signed-off-by: Maciej S. Szmigiero
---
drivers/media/pci/saa7134/saa7134-i2c.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
firmware load is done with its i2c gate closed anyway so it is
not affected by this change.
Signed-off-by: Maciej S. Szmigiero
---
This replaces the "media: saa7134: keep demod i2c gate open on Medion 7134"
submission as it used an inverted open / closed terminology by mistake.
drivers
load is done with its i2c gate open anyway so it is not
affected by this change.
Signed-off-by: Maciej S. Szmigiero
---
drivers/media/pci/saa7134/saa7134-dvb.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/media/pci/saa7134/saa7134-dvb.c
b/drivers/media/pci/saa7134
Use ARRAY_SIZE for computing element count of cxusub_medion_pin_config
array as suggested by the kbuild test robot.
Reported-by: kbuild test robot
Signed-off-by: Maciej S. Szmigiero
---
drivers/media/usb/dvb-usb/cxusb-analog.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
From: "Maciej S. Szmigiero"
When retpolines are enabled they have high overhead in the inner loop
inside kvm_handle_hva_range() that iterates over the provided memory area.
Implement a static dispatch there, just like commit 7a02674d154d
("KVM: x86/mmu: Avoid retpoline
From: "Maciej S. Szmigiero"
The current memslot code uses a (reverse) gfn-ordered memslot array for
keeping track of them.
This only allows quick binary search by gfn, quick lookup by hva is not
possible (the implementation has to do a linear scan of the whole memslot
array)
From: "Maciej S. Szmigiero"
The KVM selftest framework was using a simple list for keeping track of
the memslots currently in use.
This resulted in lookups and adding a single memslot being O(n), the
later due to linear scanning of the existing memslot set to check for
the prese
From: "Maciej S. Szmigiero"
This benchmark contains the following tests:
* Map test, where the host unmaps guest memory while the guest writes to
it (maps it).
The test is designed in a way to make the unmap operation on the host
take a negligible amount of time in comparison with t
On 01.02.2021 09:21, Paolo Bonzini wrote:
On 01/02/21 09:13, Maciej S. Szmigiero wrote:
static int kvm_handle_hva_range(struct kvm *kvm,
unsigned long start,
unsigned long end,
@@ -1495,8 +1534,9 @@ static int kvm_handle_hva_range(struct kvm *kvm
On 03.02.2021 15:21, Vitaly Kuznetsov wrote:
"Maciej S. Szmigiero" writes:
On 03.02.2021 00:43, Sean Christopherson wrote:
On Tue, Feb 02, 2021, Maciej S. Szmigiero wrote:
On 02.02.2021 02:33, Sean Christopherson wrote:
...
I guess you mean to still turn id_to_index into a
On 03.02.2021 14:41, Paolo Bonzini wrote:
On 02/02/21 23:42, Maciej S. Szmigiero wrote:
I'm not opposed to using more sophisticated storage for the gfn lookups, but
only if there's a good reason for doing so. IMO, the
rbtree isn't simpler, just different.
And it also has worse cache
On 03.02.2021 15:43, Paolo Bonzini wrote:
On 01/02/21 16:19, Maciej S. Szmigiero wrote:
On 01.02.2021 09:21, Paolo Bonzini wrote:
On 01/02/21 09:13, Maciej S. Szmigiero wrote:
static int kvm_handle_hva_range(struct kvm *kvm,
unsigned long start,
unsigned
On 03.02.2021 00:43, Sean Christopherson wrote:
On Tue, Feb 02, 2021, Maciej S. Szmigiero wrote:
On 02.02.2021 02:33, Sean Christopherson wrote:
Making lookup and memslot management operations O(log(n)) brings
some performance benefits (tested on a Xeon 8167M machine):
509 slots in use:
Test
On 08.09.2019 15:29, Vitaly Wool wrote:
> z3fold_page_reclaim()'s retry mechanism is broken: on a second
> iteration it will have zhdr from the first one so that zhdr
> is no longer in line with struct page. That leads to crashes when
> the system is stressed.
>
> Fix that by moving zhdr
On 23.01.2018 10:37, Jia-Ju Bai wrote:
> The function synth_alloc_pages is not called in atomic context.
> Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
>
> Signed-off-by: Jia-Ju Bai
> ---
> sound/pci/emu10k1/memory.c |2 +-
> 1 file changed, 1 insertion(+), 1
On 17.01.2018 21:02, Nicolin Chen wrote:
> On Wed, Jan 17, 2018 at 08:38:48PM +0100, Maciej S. Szmigiero wrote:
>
>> However, I have a small nitpick regarding a comment newly added in
>> this version of patch 16:
>> +/*
>> + * Do not set SSI d
601 - 700 of 936 matches
Mail list logo
