* Re: question: crda timeout in cfg80211
From: Johannes Berg @ 2019-04-08 19:06 UTC (permalink / raw)
To: Sergey Matyukevich, linux-wireless@vger.kernel.org; +Cc: Igor Mitsyanko
In-Reply-To: <20190326124209.j6tdk5cz47kc6mdj@bars>
On Tue, 2019-03-26 at 12:42 +0000, Sergey Matyukevich wrote:
> Hi all,
>
> Linux cfg80211 regulatory subsystem uses CRDA timeout to ensure completion
> of regulatory updates, performed by user-space software. See call_crda
> functon in net/wireless/reg.c:
>
> static int call_crda(const char *alpha2)
> {
> ...
>
> queue_delayed_work(system_power_efficient_wq,
> &crda_timeout, msecs_to_jiffies(3142));
> return 0;
> }
>
> So regulatory update/reset operations shall be completed in 3142 msec.
> And that includes processing of regulatory notifiers for all the
> wireless cards in the system.
>
> It is not quite clear where this specific timeout value came from.
> Original commit (a90c7a313a1c5b) doesn't go into details about it.
>
> Any ideas where it could come from ?
No particular reason. It's just ~pi seconds, and IIRC Luis thought that
was funny :-)
Are you seeing any issues with that?
johannes
^ permalink raw reply
* Re: [PATCH v6 12/20] kvm/vmx: Emulate MSR TEST_CTL
From: Sean Christopherson @ 2019-04-08 17:48 UTC (permalink / raw)
To: Xiaoyao Li
Cc: Thomas Gleixner, Fenghua Yu, Ingo Molnar, Borislav Petkov,
H Peter Anvin, Dave Hansen, Paolo Bonzini, Ashok Raj,
Peter Zijlstra, Kalle Valo, Michael Chan, Ravi V Shankar,
linux-kernel, x86, linux-wireless, netdev, kvm
In-Reply-To: <423f329a8e194d799c6c41470266a04a9f90bc84.camel@linux.intel.com>
On Mon, Apr 08, 2019 at 05:54:25PM +0800, Xiaoyao Li wrote:
> On Fri, 2019-04-05 at 14:30 +0200, Thomas Gleixner wrote:
> > On Wed, 3 Apr 2019, Fenghua Yu wrote:
> > > @@ -1663,6 +1663,12 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct
> > > msr_data *msr_info)
> > > u32 index;
> > >
> > > switch (msr_info->index) {
> > > + case MSR_TEST_CTL:
> > > + if (!msr_info->host_initiated &&
> > > + !(vcpu->arch.core_capability & CORE_CAP_SPLIT_LOCK_DETECT))
> >
> > Errm? If the MSR_TEST_CTL is exposed to the guest via CPUID then the
> > rdmsr() in the guest is not supposed to fail just because
> > CORE_CAP_SPLIT_LOCK_DETECT is not set.
>
> you're right.
>
> > vmx->msr_test_ctl holds the proper value, which is either 0 or
> > CORE_CAP_SPLIT_LOCK_DETECT until more bits are supported.
> >
> > So the chek needs to be guest_cpuid_has(X86_FEATURE_CORE_CAPABILITY).
>
> I don't think so. There is no dependecy between
> guest_cpuid_has(X86_FEATURE_CORE_CAPABILITY) and MSR_TEST_CTL.
> guest_cpuid_has(X86_FEATURE_CORE_CAPABILITY) only indicates that guest has MSR
> CORE_CAPABILITY.
>
> Due to the fact that MSR_TEST_CTL is emulated with vmx->msr_test_ctl. I think it
> 's ok to always let userspace or guest to read MSR_TEST_CTL, it just returns the
> emulated value. Like you said, " vmx->msr_test_ctl holds the proper value, which
> is either 0 or CORE_CAP_SPLIT_LOCK_DETECT until more bits are supported."
Assuming the next version implements "vmx->msr_test_ctl_mask", KVM should
inject #GP if the guest attempts RDMSR(MSR_TEST_CTL) and the mask is zero.
It stands to reason that a kernel can only reasonably assume the MSR exists
if the (virtual) CPU supports at least one feature enabled via MSR_TEST_CTL.
^ permalink raw reply
* Re: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in simulate fw crash
From: Michał Kazior @ 2019-04-08 17:27 UTC (permalink / raw)
To: Wen Gong; +Cc: Wen Gong, linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <54b4dab1191d41b8b329f3ceb7017626@aptaiexm02f.ap.qualcomm.com>
On Mon, 8 Apr 2019 at 12:20, Wen Gong <wgong@qti.qualcomm.com> wrote:
> > -----Original Message-----
> > From: Wen Gong
> > Sent: Monday, April 1, 2019 2:11 PM
> > To: 'Michał Kazior' <kazikcz@gmail.com>
> > Cc: Wen Gong <wgong@codeaurora.org>; linux-wireless <linux-
> > wireless@vger.kernel.org>; ath10k@lists.infradead.org
> > Subject: RE: [EXT] Re: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in
> > simulate fw crash
> >
> > >
> > > If it's still bothering you then please consider a crash counter
> > > threshold so that, e.g. after 5 crash-while-restarting it's going to
> > > give up. However I doubt it's worth the effort. My experience tells me
> > > firmware crashes during recovery are rarely, if at all, transient.
> > >
> > > The simulated fw crash is not representative here. It's a mere tool to
> > > test driver code.
> > >
> > Hi Michal,
> > There have a stress test case for the simulate fw crash, it will simulate fw
> > crash
> > in a very short time for each test, this will trigger the stress test fail.
> > The simulate fw crash process should not be run parallel, after this patch, the
> > Stress test case will pass.
> > >
>
> Hi Michał,
> Do you have some new comments?
My original use case was to be able to exercise the driver's
robustness in handling nested fw crashes, IOW crash-within-a-crash.
Your test case, as far as I understand, intends to perform
consecutive, non-nested fw crash simulation stress test.
Both of these are mutually exclusive and your patch fixes your test
case at the expense of breaking my original case.
To satisfy both I would suggest you either expose ar->state via
debugfs and make your test procedure wait for that to get back into ON
state before simulating a crash again, or to extend the set of current
simulate_fw_crash commands (currently just: soft, hard, assert,
hw-restart) to something that allows expressing the intent whether
crash-in-crash prevention is intended (your case) or not (my original
case).
This could be for example something like this:
echo soft wait-ready > simulate_fw_crash
The "wait-ready" extra keyword would imply crash-in-crash prevention.
This would keep existing tools working (both behavior and syntax) and
would allow your test case to be implemented.
Michał
^ permalink raw reply
* Re: [PATCH 09/12] pinctrl: sunxi: Prepare for alternative bias voltage setting methods
From: Ondřej Jirman @ 2019-04-08 13:08 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta,
open list:DRM PANEL DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel@vger.kernel.org, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
open list:GPIO SUBSYSTEM
In-Reply-To: <CACRpkdY=G0rpxVZL8TKJOQcf+Na8o5_FwG0EyBfb-ZCYXi=_oA@mail.gmail.com>
Hi Linus,
On Mon, Apr 08, 2019 at 02:53:58PM +0200, Linus Walleij wrote:
> On Sat, Apr 6, 2019 at 1:45 AM <megous@megous.com> wrote:
>
> > From: Ondrej Jirman <megous@megous.com>
> >
> > H6 has a different I/O voltage bias setting method than A80. Prepare
> > existing code for using alternative bias voltage setting methods.
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> > drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 2 +-
> > drivers/pinctrl/sunxi/pinctrl-sunxi.c | 38 ++++++++++++-----------
> > drivers/pinctrl/sunxi/pinctrl-sunxi.h | 4 ++-
>
> I need Maxime's ACK on these patches to merge.
>
> Can the pinctrl parts be applied independently of the rest
> of the changes when Maxime is happy with the patches?
Yes, the two pinctrl patches are independent of the rest of the series.
thank you,
Ondrej
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 09/12] pinctrl: sunxi: Prepare for alternative bias voltage setting methods
From: Linus Walleij @ 2019-04-08 12:53 UTC (permalink / raw)
To: megous
Cc: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta,
open list:DRM PANEL DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel@vger.kernel.org, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
open list:GPIO SUBSYSTEM
In-Reply-To: <20190405234514.6183-10-megous@megous.com>
On Sat, Apr 6, 2019 at 1:45 AM <megous@megous.com> wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> H6 has a different I/O voltage bias setting method than A80. Prepare
> existing code for using alternative bias voltage setting methods.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 2 +-
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 38 ++++++++++++-----------
> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 4 ++-
I need Maxime's ACK on these patches to merge.
Can the pinctrl parts be applied independently of the rest
of the changes when Maxime is happy with the patches?
Yours,
Linus Walleij
^ permalink raw reply
* Re: wireless-regdb: Please update regulatory rules for Japan (JP) on 60GHz
From: seth.forshee @ 2019-04-08 12:48 UTC (permalink / raw)
To: junping.xu@jaguarwave.com; +Cc: wireless-regdb, linux-wireless
In-Reply-To: <2019040118074276659215@jaguarwave.com>
On Mon, Apr 01, 2019 at 06:07:44PM +0800, junping.xu@jaguarwave.com wrote:
> Hi Forsheee,
> The 60GHz band defined for Japan was between 59-66GHz, but is has been Updated to support 57-66Ghz about 2 years ago。
> However, the latest wireless-regdb still containning the original regulatory information as below. Please help to check the infomation
> and update the regulatory.bin.
>
> db.txt:
> ......
> country JP: DFS-JP
> (2402 - 2482 @ 40), (20)
> (2474 - 2494 @ 20), (20), NO-OFDM
> (4910 - 4990 @ 40), (23)
> (5030 - 5090 @ 40), (23)
> (5170 - 5250 @ 80), (20), AUTO-BW
> (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> (5490 - 5710 @ 160), (23), DFS
> # 60 GHz band channels 2-4 at 10mW,
> # ref: http://www.arib.or.jp/english/html/overview/doc/1-STD-T74v1_1.pdf
The only change which is required to change:
> (59000 - 66000 @ 2160), (10 mW)
to:
(57000 - 66000 @ 2160), (10 mW)
Is that right? Can you provide a link to the documentation which
supports this change? The current link above this rule appears to be
broken.
Thanks,
Seth
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 00/12] Add support for Orange Pi 3
From: Ondřej Jirman @ 2019-04-08 12:46 UTC (permalink / raw)
To: Jagan Teki
Cc: Clément Péron, linux-sunxi, Maxime Ripard, Chen-Yu Tsai,
Rob Herring, Linus Walleij, David Airlie, Daniel Vetter,
Mark Rutland, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
David S. Miller, Maxime Coquelin, Arend van Spriel, Franky Lin,
Hante Meuleman, Chi-Hsien Lin, Wright Feng, Kalle Valo,
Naveen Gupta, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, netdev, linux-stm32, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, linux-gpio
In-Reply-To: <CAMty3ZDpppM5zBvxCBx3NjdVsRm4S93yz5kqi5Z5a0rhC-+zPg@mail.gmail.com>
Hi Jagan,
On Mon, Apr 08, 2019 at 11:31:22AM +0530, Jagan Teki wrote:
> On Sun, Apr 7, 2019 at 8:02 PM 'Ondřej Jirman' via linux-sunxi
> <linux-sunxi@googlegroups.com> wrote:
> >
> > On Sun, Apr 07, 2019 at 03:36:21PM +0200, Clément Péron wrote:
> > > Hi,
> > >
> > > On Sat, 6 Apr 2019 at 01:45, megous via linux-sunxi
> > > <linux-sunxi@googlegroups.com> wrote:
> > > >
> > > > From: Ondrej Jirman <megous@megous.com>
> > > >
> > > > This series implements support for Xunlong Orange Pi 3 board.
> > >
> > > OrangePi 3 Lite2 and One Plus boards support has already been merged.
> > > The support is not complete but you should rebase your patches on top
> > > of sunxi/for-next
> >
> > Hi,
> >
> > OrangePi 3 is somewhat different from these two boards (mostly it has a differnt
> > power tree). It doesn't use the AXP regulators that are defined in the
> > sun50i-h6-orangepi.dtsi in the same way.
> >
> > For example:
> >
> > - bldo3 (is turned always on in sun50i-h6-orangepi.dtsi but unused for opi3)
> > - cldo2 and cldo3 are unused on opi3 and have nothing to do with WiFi
> > - aldo3 is not for dram
> > - bldo1 on the other hand is for dram on opi3
> > - some other regulators are used for different/more functions and thus
> > named differntly
> > - USB id-det pin is differnt
> > - ...
>
> Based on my communication with OrangePI, OPI-3 has PCIE, 4 USB-3.0
> ports and AV are the key differences and rest seems to be similar. but
> if we have a diff or unused regulators may be we can't enable them in
> dtsi (I never looked that close as of now)
These regulators are not just disabled on Opi 3, they have different/no meaning.
Schematics allow for high amount of variability in the power tree (see all the
NC (not connected) / 0R resistors) in the schematic around AXP805. Every board
based on this Xunlong design can be subtly different.
I already suggested a maintainable solution, below. Where base dtsi has empty
config for regulators and every board based on that just defines it completely
for itself.
A few regulators (for CPU/GPU) will most probably have the same meaning on every
derived board, so these can probably be kept in dtsi without causing too much
annoyance.
It's unpleasant to have wrong regulator setup defined in an underlying dtsi, and
then trying to override it by removing/adding random properties in the board dts
for the new boards based on that, so that it fits.
The rest of the current HW descriptions in the sun50i-h6-orangepi.dtsi can be
shared (as of now).
thank you and regards,
o.
^ permalink raw reply
* Re: [wireless-regdb] [PATCH] wireless-regdb: Update regulatory rules for South Korea
From: Seth Forshee @ 2019-04-08 12:41 UTC (permalink / raw)
To: Peter Oh; +Cc: wireless-regdb@lists.infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1553711659-27600-1-git-send-email-peter.oh@bowerswilkins.com>
On Wed, Mar 27, 2019 at 06:34:29PM +0000, Peter Oh wrote:
> From: Peter Oh <peter.oh@bowerswilkins.com>
>
> Update power limit as documented in:
> https://www.rra.go.kr/FileDownSvl?file_type=LAWKR&file_parentseq=54&file_seq=27
> which revised on November 30, 2016.
>
> Signed-off-by: Peter Oh <peter.oh@bowerswilkins.com>
I usually try to check the changes against the documents, but in this
case I haven't been able to get any English tranlation for the document
(or even view the contents it in any meaningful way). I don't suppose
you know where to find an English version of the document?
Thanks,
Seth
> ---
> db.txt | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/db.txt b/db.txt
> index 4fb1948..52c17e9 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -695,11 +695,12 @@ country KP: DFS-JP
> (5735 - 5815 @ 20), (30)
>
> country KR: DFS-JP
> - (2402 - 2482 @ 40), (13)
> - (5170 - 5250 @ 80), (20), AUTO-BW
> - (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> - (5490 - 5710 @ 160), (30), DFS
> - (5735 - 5835 @ 80), (30)
> + # ref: https://www.rra.go.kr/ko/reference/lawList_view.do?lw_seq=54&lw_type=3&searchCon=&lw_select=ALL&lw_model=&searchTxt=
> + (2402 - 2482 @ 40), (23)
> + (5170 - 5250 @ 80), (17), AUTO-BW
> + (5250 - 5330 @ 80), (23), DFS, AUTO-BW
> + (5490 - 5710 @ 160), (23), DFS
> + (5735 - 5835 @ 80), (23)
> # 60 GHz band channels 1-4,
> # ref: http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EB%AC%B4%EC%84%A0%EC%84%A4%EB%B9%84%EA%B7%9C%EC%B9%99
> (57000 - 66000 @ 2160), (43)
> --
> 2.7.4
>
>
> _______________________________________________
> wireless-regdb mailing list
> wireless-regdb@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/wireless-regdb
^ permalink raw reply
* [PATCH] mac80211: only allocate one queue when using iTXQs
From: Johannes Berg @ 2019-04-08 12:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
There's no need to allocate than one queue in the iTXQs case
now that we no longer use ndo_select_queue to assign the AC.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/iface.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 6e1b031535d5..94459b2b3d2a 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1763,13 +1763,13 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
txq_size += sizeof(struct txq_info) +
local->hw.txq_data_size;
- if (local->ops->wake_tx_queue)
+ if (local->ops->wake_tx_queue) {
if_setup = ieee80211_if_setup_no_queue;
- else
+ } else {
if_setup = ieee80211_if_setup;
-
- if (local->hw.queues >= IEEE80211_NUM_ACS)
- txqs = IEEE80211_NUM_ACS;
+ if (local->hw.queues >= IEEE80211_NUM_ACS)
+ txqs = IEEE80211_NUM_ACS;
+ }
ndev = alloc_netdev_mqs(size + txq_size,
name, name_assign_type,
--
2.17.2
^ permalink raw reply related
* Re: [PATCH] mac80211: optimize skb resizing
From: Johannes Berg @ 2019-04-08 12:26 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless
In-Reply-To: <20190317181859.71841-1-nbd@nbd.name>
On Sun, 2019-03-17 at 19:18 +0100, Felix Fietkau wrote:
> When forwarding unicast packets from ethernet to batman-adv over 802.11s
> (with forwarding disabled), the typical required headroom to transmit
> encrypted packets on mt76 is 32 (802.11) + 6 (802.11s) + 8 (CCMP) +
> 2 (padding) + 6 (LLC) + 18 (batman-adv) - 14 (old ethernet header) = 58 bytes.
>
> On systems where NET_SKB_PAD is 64 this leads to a call to pskb_expand_head
> for every packet, since mac80211 also tries to allocate 16 bytes status
> headroom for radiotap headers.
>
> This patch fixes these unnecessary reallocations by only requiring the extra
> status headroom in ieee80211_tx_monitor()
> If however a reallocation happens before that call, the status headroom gets
> added there as well, in order to avoid double reallocation.
>
> The patch also cleans up the code by moving the headroom calculation to
> ieee80211_skb_resize.
This doesn't apply, not really sure why.
johannes
^ permalink raw reply
* Re: [PATCH 06/16] mac80211_hwsim: make copying of ciphers safer by checking the length
From: Johannes Berg @ 2019-04-08 12:22 UTC (permalink / raw)
To: Luca Coelho, kvalo; +Cc: linux-wireless, Luca Coelho
In-Reply-To: <20190315163634.17315-7-luca@coelho.fi>
On Fri, 2019-03-15 at 18:36 +0200, Luca Coelho wrote:
> From: Luca Coelho <luciano.coelho@intel.com>
>
> Make sure the length of the ciphers we are copying never exceeds the
> space we have for storing them. There is no risk of overcopying at
> the moment, because we check n_params before, but this makes this
> function safer in case someone changes something in the future.
I don't think this makes sense.
If anything, we should pass extack to mac80211_hwsim_new_radio() and do
the entire validation there, but doing the same thing twice in two
places just because of static checkers is useless.
johannes
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 02/12] drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
From: Ondřej Jirman @ 2019-04-08 12:17 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, linux-sunxi, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
open list:GPIO SUBSYSTEM
In-Reply-To: <20190408084714.b6xdi2pxbjvzwsnu@flea>
On Mon, Apr 08, 2019 at 10:47:14AM +0200, Maxime Ripard wrote:
> On Mon, Apr 08, 2019 at 03:28:24PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Apr 8, 2019 at 3:23 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Sat, Apr 06, 2019 at 01:45:04AM +0200, megous@megous.com wrote:
> > > > From: Ondrej Jirman <megous@megous.com>
> > > >
> > > > Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected
> > > > transistors, before it can be used. Model this as a power supply for DDC
> > > > (via regulator framework).
> > > >
> > > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > >
> > > The DDC bus itself is usually attached to the HDMI connector, so it
> > > would make sense to make the supply also a property of the connector.
> >
> > I believe these are separate things. What this patch covers is power for
> > a voltage shifter between the SoC and HDMI DDC pins. The HDMI connector's
> > 5V supply to power the remote DDC chip is something else. And on the
> > Orange Pi 3 they are indeed separate supplies.
>
> Then maybe the endpoint link between the two would be the best place
> to put this?
Interestingly &hdmi node configures the DDC bus pins via pinctrl on the SoC
side, so I put this there too, because it's related to those pins. I'm not sure
if that changes anything in the discussion.
regards,
o.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* Re: [PATCH 1/2] nl80211: Allow change CW to Ad-Hock network
From: Johannes Berg @ 2019-04-08 12:12 UTC (permalink / raw)
To: Andrea Greco; +Cc: David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190221231147.6141-1-andrea.greco.gapmilano@gmail.com>
On Fri, 2019-02-22 at 00:11 +0100, Andrea Greco wrote:
> From: Andrea Greco <a.greco@4sigma.it>
>
> Add net-link support for change CW in Ad-Hock network
This doesn't really make sense, the ibss code overrides it again once it
actually re-joins etc.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Honor SW_CRYPTO_CONTROL in AP VLAN mode
From: Johannes Berg @ 2019-04-08 12:09 UTC (permalink / raw)
To: Alexander Wetzel; +Cc: linux-wireless, mpubbise
In-Reply-To: <20190209140138.16692-1-alexander@wetzel-home.de>
On Sat, 2019-02-09 at 15:01 +0100, Alexander Wetzel wrote:
> Restore @SW_CRYPTO_CONTROL when interface is in AP Vlan mode and don't
> override driver decision for unicast keys.
>
> Fixes commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto
> controlled devices"), which should only have allow SW crypto fallback for
> group keys.
This confuses me.
The driver doesn't really know about AP_VLAN, so the original commit
intentionally did this, I think?
There was some kind of other fix related to this though?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac8011: Add support for NL80211_STA_INFO_RX_MCAST_BCAST
From: Johannes Berg @ 2019-04-08 12:02 UTC (permalink / raw)
To: Narayanraddi Masti; +Cc: linux-wireless
In-Reply-To: <1549570566-28658-2-git-send-email-team.nmasti@gmail.com>
On Thu, 2019-02-07 at 12:16 -0800, Narayanraddi Masti wrote:
> Add support to collect per STA mcast/bcast packet information attribute
> NL80211_STA_INFO_RX_MCAST_BCAST.
This, honestly, I'm not a fan of.
We've added far too many statistics already, and we keep adding more.
This, in particular, also adds a bunch of 64-bit counters (is that
really needed?) which is relatively expensive on 32-bit platforms, and
it didn't even update the fast-RX path properly.
I really think we need to stick some eBPF hooks somewhere late enough to
get valid data, but early enough to get all the data, and then you can
keep all your favourite statistics there.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: Add support for NL80211_STA_INFO_AIRTIME_LINK_METRIC
From: Johannes Berg @ 2019-04-08 11:59 UTC (permalink / raw)
To: Narayanraddi Masti; +Cc: linux-wireless
In-Reply-To: <1549570566-28658-1-git-send-email-team.nmasti@gmail.com>
On Thu, 2019-02-07 at 12:16 -0800, Narayanraddi Masti wrote:
> Add support for mesh airtime link metric attribute
> NL80211_STA_INFO_AIRTIME_LINK_METRIC.
This looks good, applied.
johannes
^ permalink raw reply
* Re: [PATCHv2 2/2] mac80211: Implement API to configure station specific rssi threshold
From: Johannes Berg @ 2019-04-08 11:56 UTC (permalink / raw)
To: Tamizh chelvam; +Cc: linux-wireless
In-Reply-To: <1549361181-6237-3-git-send-email-tamizhr@codeaurora.org>
> +++ b/net/mac80211/cfg.c
> @@ -3889,6 +3889,110 @@ static int ieee80211_get_txq_stats(struct wiphy *wiphy,
> return drv_abort_pmsr(local, sdata, request);
> }
>
> +void sta_mon_rssi_config_free(struct sta_info *sta)
> +{
> + if (sta->rssi_config) {
> + kfree_rcu(sta->rssi_config, rcu_head);
> + sta->rssi_config = NULL;
> + }
> +}
This looks wrong, you should use RCU_INIT_POINTER()?
And you should do it the other way around I think? I.e.
old = sta->rssi_config;
RCU_INIT_POINTER(sta->rssi_config, NULL);
kfree_rcu(old, rcu_head);
> /*
> * The bandwidth threshold below which the per-station CoDel parameters will be
> * scaled to be more lenient (to prevent starvation of slow stations). This
> @@ -623,6 +650,7 @@ struct sta_info {
>
> struct cfg80211_chan_def tdls_chandef;
>
> + struct sta_mon_rssi_config *rssi_config;
Please add documentation (as built bot pointed out shortly after patch
posting!)
johannes
^ permalink raw reply
* Re: [PATCHv2 1/2] cfg80211: Add support to configure station specific RSSI threshold for AP mode
From: Johannes Berg @ 2019-04-08 11:54 UTC (permalink / raw)
To: Tamizh chelvam; +Cc: linux-wireless
In-Reply-To: <1549361181-6237-2-git-send-email-tamizhr@codeaurora.org>
On Tue, 2019-02-05 at 15:36 +0530, Tamizh chelvam wrote:
>
> + [NL80211_ATTR_CQM] = {
> + .type = NLA_NESTED,
> + .validation_data = nl80211_attr_cqm_policy,
> + },
This is wrong, you need to use NLA_POLICY_NESTED().
> + [NL80211_ATTR_STA_MON_FIXED_THOLD] = { .type = NLA_U8 },
Please use NLA_POLICY_RANGE(NLA_U8, 0, 1).
Also, I'm not sure I really understand the documentation for this value.
> /* Check all values negative and sorted */
> - for (i = 0; i < n_thresholds; i++) {
> + for (i = 0; i < n_tholds; i++) {
Why rename the perfectly fine variable to some abbreviation?
johannes
^ permalink raw reply
* Re: [PATCH v8 00/14] rtw88: mac80211 driver for Realtek 802.11ac wireless network chips
From: Kalle Valo @ 2019-04-08 11:33 UTC (permalink / raw)
To: Tony Chuang
Cc: Brian Norris, Johannes Berg, linux-wireless, Greg Kroah-Hartman,
Pkshih, Andy Huang, Larry Finger, Stanislaw Gruszka
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D17D50A4@RTITMBSVM04.realtek.com.tw>
Tony Chuang <yhchuang@realtek.com> writes:
> Hi Kalle
>
>> From: Stanislaw Gruszka [mailto:sgruszka@redhat.com]
>> Sent: Wednesday, March 27, 2019 6:26 PM
>> To: Tony Chuang
>> Cc: Brian Norris; Kalle Valo; Johannes Berg; linux-wireless; Greg Kroah-Hartman;
>> Pkshih; Andy Huang; Larry Finger
>> Subject: Re: [PATCH v8 00/14] rtw88: mac80211 driver for Realtek 802.11ac
>> wireless network chips
>>
>
> It's just a gentle reply to ask if rtw88 is getting merged.
> Are you still reviewing or is there anything I can help.
I just have been busy with other stuff, sorry. I'll try find time for
this soon.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in simulate fw crash
From: Wen Gong @ 2019-04-08 10:19 UTC (permalink / raw)
To: Michał Kazior; +Cc: Wen Gong, linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <02904ba8682441e1a89668c1345cbec9@aptaiexm02f.ap.qualcomm.com>
> -----Original Message-----
> From: Wen Gong
> Sent: Monday, April 1, 2019 2:11 PM
> To: 'Michał Kazior' <kazikcz@gmail.com>
> Cc: Wen Gong <wgong@codeaurora.org>; linux-wireless <linux-
> wireless@vger.kernel.org>; ath10k@lists.infradead.org
> Subject: RE: [EXT] Re: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in
> simulate fw crash
>
> >
> > If it's still bothering you then please consider a crash counter
> > threshold so that, e.g. after 5 crash-while-restarting it's going to
> > give up. However I doubt it's worth the effort. My experience tells me
> > firmware crashes during recovery are rarely, if at all, transient.
> >
> > The simulated fw crash is not representative here. It's a mere tool to
> > test driver code.
> >
> Hi Michal,
> There have a stress test case for the simulate fw crash, it will simulate fw
> crash
> in a very short time for each test, this will trigger the stress test fail.
> The simulate fw crash process should not be run parallel, after this patch, the
> Stress test case will pass.
> >
Hi Michał,
Do you have some new comments?
> > Michał
^ permalink raw reply
* Re: [PATCH v6 12/20] kvm/vmx: Emulate MSR TEST_CTL
From: Xiaoyao Li @ 2019-04-08 9:54 UTC (permalink / raw)
To: Thomas Gleixner, Fenghua Yu
Cc: Ingo Molnar, Borislav Petkov, H Peter Anvin, Dave Hansen,
Paolo Bonzini, Ashok Raj, Peter Zijlstra, Kalle Valo,
Michael Chan, Ravi V Shankar, linux-kernel, x86, linux-wireless,
netdev, kvm
In-Reply-To: <alpine.DEB.2.21.1904051400230.1802@nanos.tec.linutronix.de>
Hi, Thomas,
On Fri, 2019-04-05 at 14:30 +0200, Thomas Gleixner wrote:
> On Wed, 3 Apr 2019, Fenghua Yu wrote:
> > @@ -1663,6 +1663,12 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct
> > msr_data *msr_info)
> > u32 index;
> >
> > switch (msr_info->index) {
> > + case MSR_TEST_CTL:
> > + if (!msr_info->host_initiated &&
> > + !(vcpu->arch.core_capability & CORE_CAP_SPLIT_LOCK_DETECT))
>
> Errm? If the MSR_TEST_CTL is exposed to the guest via CPUID then the
> rdmsr() in the guest is not supposed to fail just because
> CORE_CAP_SPLIT_LOCK_DETECT is not set.
you're right.
> vmx->msr_test_ctl holds the proper value, which is either 0 or
> CORE_CAP_SPLIT_LOCK_DETECT until more bits are supported.
>
> So the chek needs to be guest_cpuid_has(X86_FEATURE_CORE_CAPABILITY).
I don't think so. There is no dependecy between
guest_cpuid_has(X86_FEATURE_CORE_CAPABILITY) and MSR_TEST_CTL.
guest_cpuid_has(X86_FEATURE_CORE_CAPABILITY) only indicates that guest has MSR
CORE_CAPABILITY.
Due to the fact that MSR_TEST_CTL is emulated with vmx->msr_test_ctl. I think it
's ok to always let userspace or guest to read MSR_TEST_CTL, it just returns the
emulated value. Like you said, " vmx->msr_test_ctl holds the proper value, which
is either 0 or CORE_CAP_SPLIT_LOCK_DETECT until more bits are supported."
> > + return 1;
> > + msr_info->data = vmx->msr_test_ctl;
> > + break;
> > #ifdef CONFIG_X86_64
> > case MSR_FS_BASE:
> > msr_info->data = vmcs_readl(GUEST_FS_BASE);
> > @@ -1797,6 +1803,14 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct
> > msr_data *msr_info)
> > u32 index;
> >
> > switch (msr_index) {
> > + case MSR_TEST_CTL:
> > + if (!(vcpu->arch.core_capability & CORE_CAP_SPLIT_LOCK_DETECT))
> > + return 1;
>
> Again, this wants to be a check for the availability of the MSR in the
> guest cpuid and not to the CORE_CAP_SPLIT_LOCK_DETECT magic bit.
>
> > +
> > + if (data & ~TEST_CTL_ENABLE_SPLIT_LOCK_DETECT)
> > + return 1;
>
> and this one wants to be:
>
> if (data & vmx->msr_test_ctl_mask)
>
> so additional bits can be enabled later on at exactly one point in the
> code, i.e. during vm init.
Again, in wrmsr handler, since MSR_TEST_CTL is emulated, it can be considered
that guest always has this MSR. It just needs to return 1 when reserved bits are
set.
Using vmx->msr_test_ctl_mask is a good idea. I will use it in next version.
> > + vmx->msr_test_ctl = data;
> > + break;
> >
> > +static void atomic_switch_msr_test_ctl(struct vcpu_vmx *vmx)
> > +{
> > + u64 host_msr_test_ctl;
> > +
> > + /* if TEST_CTL MSR doesn't exist on the hardware, do nothing */
> > + if (rdmsrl_safe(MSR_TEST_CTL, &host_msr_test_ctl))
> > + return;
>
> Yikes. So on hosts which do not have MSR_TEST_CTL this takes a fault on
> every VM enter. The host knows whether it has this MSR or not.
>
> Even if it exists there is no point to do the rdmsr on every vmenter. The
> value should be cached per cpu. It only changes when:
>
> 1) #AC triggers in kernel space
>
> 2) The sysfs knob is flipped
>
> #1 It happens either _BEFORE_ or _AFTER_ atomic_switch_msr_test_ctl(). In
> both cases the cached value is correct in atomic_switch_msr_test_ctl().
>
> If it happens _AFTER_ atomic_switch_msr_test_ctl() then the VMEXIT will
> restore the enabled bit, but there is nothing you can do about that.
>
> #2 CANNOT happen in the context of vcpu_run().
>
> So this wants to be:
>
> host_msr_test_ctl = this_cpu_read(msr_test_ctl_cache);
You're right and thanks for your advice.
I will take it in next version.
> > + if (host_msr_test_ctl == vmx->msr_test_ctl)
> > + clear_atomic_switch_msr(vmx, MSR_TEST_CTL);
> > + else
> > + add_atomic_switch_msr(vmx, MSR_TEST_CTL, vmx->msr_test_ctl,
> > + host_msr_test_ctl, false);
> > +}
> > +
> > u64 kvm_get_core_capability(void)
> > {
> > - return 0;
> > + u64 data;
> > +
> > + rdmsrl_safe(MSR_IA32_CORE_CAPABILITY, &data);
>
> if (!boot_cpu_has(X86_FEATURE_CORE_CAPABILITY))
> return 0;
>
> > + /* mask non-virtualizable functions */
> > + data &= CORE_CAP_SPLIT_LOCK_DETECT;
>
> Why?
>
> > + /*
> > + * There will be a list of FMS values that have split lock detection
> > + * but lack the CORE CAPABILITY MSR. In this case, set
> > + * CORE_CAP_SPLIT_LOCK_DETECT since we emulate MSR CORE_CAPABILITY.
>
> That's completely wrong. X86_FEATURE_SPLIT_LOCK_DETECT is set when the
> capability is enumerated in CPUID or it's set via the FMS quirk.
>
> So:
> data = 0;
> > + if (boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT))
> > + data |= CORE_CAP_SPLIT_LOCK_DETECT;
> > +
> > + return data;
>
> is absolutely sufficient.
Right, X86_FEATURE_SPLIT_LOCK_DETECT is set in 2 situation:
#1 the capability is enumerated by CORE_CAP_SPLIT_LOCK_DETECT (bit 5 of
MSR_IA32_CORE_CAPABILITY)
#2 via FMS list, in which those processors have split lock detection
feature but don't have MSR_IA32_CORE_CAPABILITY.
There two pathes work well for host, accurately for real FMS.
However, when it comes to virtualization, we can emulate a different FMS of
guest from host.
Considering the following case:
The host cpu is ICELAKE_MOBILE, which doesn't have X86_FEATURE_CORE_CAPABILITY
but has X86_FEATURE_SPLIT_LOCK_DETECT.
If we run a guest with cpu model, Skylake. It will hidden the feature
X86_FEATURE_SPLIT_LOCK_DETECT from guest, since guest's MSR_IA32_CORE_CAPABILITY
reports zero, and FMS of guest doesn't match the list.
In this way, it failed to expose the X86_FEATURE_SPLIT_LOCK_DETECT to guest.
Since MSR_IA32_CORE_CAPBILITY is emulated in software for guest. We can enforce
using #1 to report X86_FEATURE_SPLIT_LOCK_DETECT of guest, thus guest can get
rid of the limitation of the FMS list.
> Thanks,
>
> tglx
^ permalink raw reply
* Re: [PATCH 0/6] stricter netlink validation
From: Johannes Berg @ 2019-04-08 9:01 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: linux-wireless, netdev, Pablo Neira Ayuso, David Ahern
In-Reply-To: <20190408090010.GG3201@mtr-leonro.mtl.com>
> This series crashes on mlx4 devices with the following kernel panic.
Yeah, I know. Like I said elsewhere on the thread, I accidentally sent
out the wrong branch (not realizing I had made two). :-(
This should work:
https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git/log/?h=netlink-validation
johannes
^ permalink raw reply
* Re: [PATCH 0/6] stricter netlink validation
From: Leon Romanovsky @ 2019-04-08 9:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Pablo Neira Ayuso, David Ahern
In-Reply-To: <20190404065408.5864-1-johannes@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 17450 bytes --]
On Thu, Apr 04, 2019 at 08:54:02AM +0200, Johannes Berg wrote:
> Here's a version that has passed build testing ;-)
>
> As mentioned in the RFC postings, this was inspired by talks
> between David, Pablo and myself. Pablo is somewhat firmly on
> the side of less strict validation, while David and myself
> are in the very strict validation camp. If I understand him
> correctly, Pablo doesn't mind the strict validation if it is
> accompanied by exposing the policy to userspace, but that
> isn't something we can do today. I'll work on it later.
>
> What this series does is basically first replace nla_parse()
> and all its friends by nla_parse_deprecated(), while making
> all of those just inlines around __nla_parse() and friends
> with configurable strict checking bits. Three versions exist
> after this patchset:
> * liberal - no bits set
> * deprecated_strict - reject attrs > maxtype
> reject trailing junk
> * new default - reject trailing junk
> reject attrs > maxtype
> reject policy entries that are NLA_UNSPEC
> require a policy
> strictly validate attributes
>
> The NLA_UNSPEC one can be opted in even in existing code with
> existing userspace in the future, as policies are updated.
>
> In addition, infrastructure is added to opt in to the strict
> attribute validation even for new attributes added to existing
> policies, regardless of the nla_parse() strictness setting
> described above, as new attributes should not be a compatibility
> issue.
>
> Finally, much of this is plumbed through generic netlink etc.,
> and I've included a patch to tag nl80211 with the future attribute
> strictness for reference.
>
> johannes
Hi Johannes,
This series crashes on mlx4 devices with the following kernel panic.
[ 92.937629] BUG: unable to handle kernel paging request at 0000000000001023
[ 92.940094] #PF error: [normal kernel read fault]
[ 92.941731] PGD 80000002291da067 P4D 80000002291da067 PUD 20f295067 PMD 0
[ 92.943983] Oops: 0000 [#1] SMP PTI
[ 92.945248] CPU: 1 PID: 3976 Comm: devlink Not tainted 5.1.0-rc2-J2742-G9070daeb7d6d #1
[ 92.947951] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 92.950921] RIP: 0010:genl_lock_dumpit+0x10/0xb0
[ 92.952502] Code: c7 c7 a0 e6 30 82 e9 ef 96 a7 ff 0f 1f 44 00 00 66
2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 46 20 48 8b
28 <0f> b6 55 23 f6 c2 02 75 4d 4c 8b 48 08 83 e2 04 4c 8b 5e 08 80 fa
[ 92.958146] RSP: 0018:ffffc90002df7c30 EFLAGS: 00010202
[ 92.959817] RAX: ffffc90002df7be8 RBX: ffff888231b0e800 RCX: 0000000000000ec0
[ 92.962079] RDX: 00000000000000a8 RSI: ffff888231b0eb30 RDI: ffff88823195b400
[ 92.964297] RBP: 0000000000001000 R08: 0000000000001ec0 R09: ffffffff81686c01
[ 92.966475] R10: ffffea0008c656c0 R11: 0000000000000040 R12: 0000000000001000
[ 92.968575] R13: ffff888231b0eb30 R14: 0000000000000000 R15: ffff888230f63700
[ 92.970688] FS: 00007fa7e963bb80(0000) GS:ffff888237a80000(0000) knlGS:0000000000000000
[ 92.973158] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 92.974895] CR2: 0000000000001023 CR3: 000000020f8fa001 CR4: 00000000003606a0
[ 92.976994] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 92.979033] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 92.981030] Call Trace:
[ 92.981870] netlink_dump+0x166/0x390
[ 92.982995] netlink_recvmsg+0x2ef/0x3e0
[ 92.984184] ? copy_msghdr_from_user+0xd5/0x150
[ 92.985540] ___sys_recvmsg+0xf5/0x250
[ 92.986685] ? netlink_sendmsg+0x120/0x3a0
[ 92.987905] ? __sys_sendto+0x10e/0x140
[ 92.989077] ? __sys_recvmsg+0x5b/0xa0
[ 92.990205] __sys_recvmsg+0x5b/0xa0
[ 92.991253] do_syscall_64+0x48/0x100
[ 92.992327] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 92.993743] RIP: 0033:0x7fa7e8d48437
[ 92.994783] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00
00 00 8b 05 1a f4 2b 00 48 63 d2 48 63 ff 85 c0 75 18 b8 2f 00 00 00 0f
05 <48> 3d 00 f0 ff ff 77 59 f3 c3 0f 1f 80 00 00 00 00 53 48 89 f3 48
[ 92.999640] RSP: 002b:00007ffcee2ae168 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
[ 93.001745] RAX: ffffffffffffffda RBX: 0000000000707320 RCX: 00007fa7e8d48437
[ 93.003556] RDX: 0000000000000000 RSI: 00007ffcee2ae190 RDI: 0000000000000012
[ 93.005383] RBP: 0000000000707260 R08: 00007fa7e900b0e0 R09: 000000000000000c
[ 93.007206] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004035e0
[ 93.009023] R13: 00007ffcee2ae348 R14: 0000000000000000 R15: 0000000000000000
[ 93.010847] Modules linked in: mlx4_en mlx4_ib mlx4_core geneve
ip6_udp_tunnel udp_tunnel bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre
ip_tunnel rdma_ucm ib_uverbs ib_ipoib ib_umad ib_srp scsi_transport_srp
rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm
ib_core [last unloaded: mlx4_core]
[ 93.016658] CR2: 0000000000001023
[ 93.017489] ---[ end trace 295441d824c2b8ba ]---
[ 93.018440] RIP: 0010:genl_lock_dumpit+0x10/0xb0
[ 93.019577] Code: c7 c7 a0 e6 30 82 e9 ef 96 a7 ff 0f 1f 44 00 00 66
2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 46 20 48 8b
28 <0f> b6 55 23 f6 c2 02 75 4d 4c 8b 48 08 83 e2 04 4c 8b 5e 08 80 fa
[ 93.023640] RSP: 0018:ffffc90002df7c30 EFLAGS: 00010202
[ 93.024836] RAX: ffffc90002df7be8 RBX: ffff888231b0e800 RCX: 0000000000000ec0
[ 93.026321] RDX: 00000000000000a8 RSI: ffff888231b0eb30 RDI: ffff88823195b400
[ 93.027867] RBP: 0000000000001000 R08: 0000000000001ec0 R09: ffffffff81686c01
[ 93.029333] R10: ffffea0008c656c0 R11: 0000000000000040 R12: 0000000000001000
[ 93.030744] R13: ffff888231b0eb30 R14: 0000000000000000 R15: ffff888230f63700
[ 93.032187] FS: 00007fa7e963bb80(0000) GS:ffff888237a80000(0000) knlGS:0000000000000000
[ 93.033881] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.035071] CR2: 0000000000001023 CR3: 000000020f8fa001 CR4: 00000000003606a0
[ 93.036502] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 93.037898] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 93.052853] BUG: unable to handle kernel paging request at ffffc90002df7be8
[ 93.054466] #PF error: [normal kernel read fault]
[ 93.055615] PGD 236931067 P4D 236931067 PUD 236934067 PMD 226489067 PTE 0
[ 93.057203] Oops: 0000 [#2] SMP PTI
[ 93.058069] CPU: 1 PID: 43 Comm: kworker/1:1 Tainted: G D 5.1.0-rc2-J2742-G9070daeb7d6d #1
[ 93.060241] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 93.062335] Workqueue: events netlink_sock_destruct_work
[ 93.063579] RIP: 0010:genl_lock_done+0xf/0x60
[ 93.064641] Code: 48 c7 c7 e0 e6 30 82 e9 8f 6f 19 00 0f 1f 44 00 00
66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 53 48 83 ec 08 48 8b 47
20 <48> 8b 28 31 c0 48 83 7d 18 00 74 2f 48 89 fb 48 c7 c7 e0 e6 30 82
[ 93.068791] RSP: 0018:ffffc90000173e50 EFLAGS: 00010286
[ 93.070042] RAX: ffffc90002df7be8 RBX: ffff888231b0e800 RCX: 0000000000000000
[ 93.071695] RDX: 0000000000000000 RSI: ffff888231b0e94c RDI: ffff888231b0eb30
[ 93.073296] RBP: ffff888231b0e800 R08: 000073746e657665 R09: 8080808080808080
[ 93.074964] R10: ffffc9000006bdf0 R11: fefefefefefefeff R12: ffff888237aa4200
[ 93.076566] R13: 0000000000000000 R14: ffff888237aa0380 R15: 0000000000000000
[ 93.078209] FS: 0000000000000000(0000) GS:ffff888237a80000(0000) knlGS:0000000000000000
[ 93.080107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.081403] CR2: ffffc90002df7be8 CR3: 0000000229700004 CR4: 00000000003606a0
[ 93.083006] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 93.084590] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 93.086277] Call Trace:
[ 93.086924] netlink_sock_destruct+0x2a/0xa0
[ 93.087949] __sk_destruct+0x24/0x180
[ 93.088817] process_one_work+0x17d/0x3b0
[ 93.089835] worker_thread+0x30/0x370
[ 93.090670] ? process_one_work+0x3b0/0x3b0
[ 93.091624] kthread+0x113/0x130
[ 93.092382] ? kthread_park+0x90/0x90
[ 93.093260] ret_from_fork+0x35/0x40
[ 93.094067] Modules linked in: mlx4_en mlx4_ib mlx4_core geneve
ip6_udp_tunnel udp_tunnel bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre
ip_tunnel rdma_ucm ib_uverbs ib_ipoib ib_umad ib_srp scsi_transport_srp
rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm
ib_core [last unloaded: mlx4_core]
[ 93.099824] CR2: ffffc90002df7be8
[ 93.100718] ---[ end trace 295441d824c2b8bb ]---
[ 93.101829] RIP: 0010:genl_lock_dumpit+0x10/0xb0
[ 93.102919] Code: c7 c7 a0 e6 30 82 e9 ef 96 a7 ff 0f 1f 44 00 00 66
2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 46 20 48 8b
28 <0f> b6 55 23 f6 c2 02 75 4d 4c 8b 48 08 83 e2 04 4c 8b 5e 08 80 fa
[ 93.107107] RSP: 0018:ffffc90002df7c30 EFLAGS: 00010202
[ 93.108382] RAX: ffffc90002df7be8 RBX: ffff888231b0e800 RCX: 0000000000000ec0
[ 93.110007] RDX: 00000000000000a8 RSI: ffff888231b0eb30 RDI: ffff88823195b400
[ 93.111941] RBP: 0000000000001000 R08: 0000000000001ec0 R09: ffffffff81686c01
[ 93.113574] R10: ffffea0008c656c0 R11: 0000000000000040 R12: 0000000000001000
[ 93.115220] R13: ffff888231b0eb30 R14: 0000000000000000 R15: ffff888230f63700
[ 93.116821] FS: 0000000000000000(0000) GS:ffff888237a80000(0000) knlGS:0000000000000000
[ 93.118937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.120592] CR2: ffffc90002df7be8 CR3: 0000000229700004 CR4: 00000000003606a0
[ 93.122196] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 93.123791] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 93.528971] BUG: unable to handle kernel paging request at 0000000000001023
[ 93.532427] #PF error: [normal kernel read fault]
[ 93.534683] PGD 8000000228100067 P4D 8000000228100067 PUD 20f87e067 PMD 0
[ 93.537776] Oops: 0000 [#3] SMP PTI
[ 93.539379] CPU: 2 PID: 4005 Comm: devlink Tainted: G D 5.1.0-rc2-J2742-G9070daeb7d6d #1
[ 93.543345] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 93.547167] RIP: 0010:genl_lock_dumpit+0x10/0xb0
[ 93.549214] Code: c7 c7 a0 e6 30 82 e9 ef 96 a7 ff 0f 1f 44 00 00 66
2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 46 20 48 8b
28 <0f> b6 55 23 f6 c2 02 75 4d 4c 8b 48 08 83 e2 04 4c 8b 5e 08 80 fa
[ 93.556214] RSP: 0018:ffffc90002e97c30 EFLAGS: 00010202
[ 93.558301] RAX: ffffc90002e97be8 RBX: ffff888232bf8800 RCX: 0000000000000ec0
[ 93.561059] RDX: 00000000000000a8 RSI: ffff888232bf8b30 RDI: ffff888228cf9700
[ 93.563644] RBP: 0000000000001000 R08: 0000000000001ec0 R09: ffffffff81686c01
[ 93.566212] R10: ffffea0008a33e40 R11: 0000000000000040 R12: 0000000000001000
[ 93.568773] R13: ffff888232bf8b30 R14: 0000000000000000 R15: ffff888225084000
[ 93.571347] FS: 00007f1754062b80(0000) GS:ffff888237b00000(0000) knlGS:0000000000000000
[ 93.574320] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.591673] CR2: 0000000000001023 CR3: 000000020f30e004 CR4: 00000000003606a0
[ 93.593943] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 93.596196] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 93.598425] Call Trace:
[ 93.599303] netlink_dump+0x166/0x390
[ 93.600509] netlink_recvmsg+0x2ef/0x3e0
[ 93.601792] ? copy_msghdr_from_user+0xd5/0x150
[ 93.603242] ___sys_recvmsg+0xf5/0x250
[ 93.604477] ? netlink_sendmsg+0x120/0x3a0
[ 93.605816] ? __sys_sendto+0x10e/0x140
[ 93.607076] ? __sys_recvmsg+0x5b/0xa0
[ 93.608308] __sys_recvmsg+0x5b/0xa0
[ 93.609503] do_syscall_64+0x48/0x100
[ 93.610649] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 93.612160] RIP: 0033:0x7f175376f437
[ 93.613295] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00
00 00 8b 05 1a f4 2b 00 48 63 d2 48 63 ff 85 c0 75 18 b8 2f 00 00 00 0f
05 <48> 3d 00 f0 ff ff 77 59 f3 c3 0f 1f 80 00 00 00 00 53 48 89 f3 48
[ 93.618540] RSP: 002b:00007ffcb7c72218 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
[ 93.620790] RAX: ffffffffffffffda RBX: 000000000186d320 RCX: 00007f175376f437
[ 93.622768] RDX: 0000000000000000 RSI: 00007ffcb7c72240 RDI: 000000000000000c
[ 93.624688] RBP: 000000000186d260 R08: 00007f1753a320e0 R09: 000000000000000c
[ 93.626610] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004035e0
[ 93.628533] R13: 00007ffcb7c723f8 R14: 0000000000000000 R15: 0000000000000000
[ 93.630457] Modules linked in: mlx4_en mlx4_ib mlx4_core geneve
ip6_udp_tunnel udp_tunnel bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre
ip_tunnel rdma_ucm ib_uverbs ib_ipoib ib_umad ib_srp scsi_transport_srp
rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm
ib_core [last unloaded: mlx4_core]
[ 93.637391] CR2: 0000000000001023
[ 93.638348] ---[ end trace 295441d824c2b8bc ]---
[ 93.639610] RIP: 0010:genl_lock_dumpit+0x10/0xb0
[ 93.640876] Code: c7 c7 a0 e6 30 82 e9 ef 96 a7 ff 0f 1f 44 00 00 66
2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 46 20 48 8b
28 <0f> b6 55 23 f6 c2 02 75 4d 4c 8b 48 08 83 e2 04 4c 8b 5e 08 80 fa
[ 93.645621] RSP: 0018:ffffc90002df7c30 EFLAGS: 00010202
[ 93.646966] RAX: ffffc90002df7be8 RBX: ffff888231b0e800 RCX: 0000000000000ec0
[ 93.648733] RDX: 00000000000000a8 RSI: ffff888231b0eb30 RDI: ffff88823195b400
[ 93.650510] RBP: 0000000000001000 R08: 0000000000001ec0 R09: ffffffff81686c01
[ 93.652283] R10: ffffea0008c656c0 R11: 0000000000000040 R12: 0000000000001000
[ 93.654061] R13: ffff888231b0eb30 R14: 0000000000000000 R15: ffff888230f63700
[ 93.655803] FS: 00007f1754062b80(0000) GS:ffff888237b00000(0000) knlGS:0000000000000000
[ 93.657761] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.658951] CR2: 0000000000001023 CR3: 000000020f30e004 CR4: 00000000003606a0
[ 93.660431] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 93.661971] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 93.684915] BUG: unable to handle kernel paging request at ffffc90002e97be8
[ 93.686561] #PF error: [normal kernel read fault]
[ 93.687650] PGD 236931067 P4D 236931067 PUD 236934067 PMD 228084067 PTE 0
[ 93.689182] Oops: 0000 [#4] SMP PTI
[ 93.690035] CPU: 2 PID: 38 Comm: kworker/2:1 Tainted: G D 5.1.0-rc2-J2742-G9070daeb7d6d #1
[ 93.692162] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 93.694147] Workqueue: events netlink_sock_destruct_work
[ 93.695381] RIP: 0010:genl_lock_done+0xf/0x60
[ 93.696387] Code: 48 c7 c7 e0 e6 30 82 e9 8f 6f 19 00 0f 1f 44 00 00
66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 53 48 83 ec 08 48 8b 47
20 <48> 8b 28 31 c0 48 83 7d 18 00 74 2f 48 89 fb 48 c7 c7 e0 e6 30 82
[ 93.700436] RSP: 0018:ffffc9000014be50 EFLAGS: 00010286
[ 93.701605] RAX: ffffc90002e97be8 RBX: ffff888232bf8800 RCX: 0000000000000000
[ 93.703153] RDX: 0000000000000000 RSI: ffff888232bf894c RDI: ffff888232bf8b30
[ 93.704712] RBP: ffff888232bf8800 R08: 000073746e657665 R09: 8080808080808080
[ 93.706351] R10: ffffc900000c3df0 R11: fefefefefefefeff R12: ffff888237b24200
[ 93.707943] R13: 0000000000000000 R14: ffff888237b20380 R15: 0000000000000000
[ 93.709567] FS: 0000000000000000(0000) GS:ffff888237b00000(0000) knlGS:0000000000000000
[ 93.711426] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.712712] CR2: ffffc90002e97be8 CR3: 000000021ce62006 CR4: 00000000003606a0
[ 93.714299] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 93.715888] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 93.717426] Call Trace:
[ 93.718093] netlink_sock_destruct+0x2a/0xa0
[ 93.719157] __sk_destruct+0x24/0x180
[ 93.720027] process_one_work+0x17d/0x3b0
[ 93.721033] worker_thread+0x30/0x370
[ 93.721946] ? process_one_work+0x3b0/0x3b0
[ 93.722926] kthread+0x113/0x130
[ 93.723753] ? kthread_park+0x90/0x90
[ 93.724606] ret_from_fork+0x35/0x40
[ 93.725494] Modules linked in: mlx4_en mlx4_ib mlx4_core geneve
ip6_udp_tunnel udp_tunnel bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre
ip_tunnel rdma_ucm ib_uverbs ib_ipoib ib_umad ib_srp scsi_transport_srp
rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm
ib_core [last unloaded: mlx4_core]
[ 93.731221] CR2: ffffc90002e97be8
[ 93.732069] ---[ end trace 295441d824c2b8bd ]---
[ 93.733128] RIP: 0010:genl_lock_dumpit+0x10/0xb0
[ 93.734186] Code: c7 c7 a0 e6 30 82 e9 ef 96 a7 ff 0f 1f 44 00 00 66
2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 46 20 48 8b
28 <0f> b6 55 23 f6 c2 02 75 4d 4c 8b 48 08 83 e2 04 4c 8b 5e 08 80 fa
[ 93.738319] RSP: 0018:ffffc90002df7c30 EFLAGS: 00010202
[ 93.739515] RAX: ffffc90002df7be8 RBX: ffff888231b0e800 RCX: 0000000000000ec0
[ 93.741111] RDX: 00000000000000a8 RSI: ffff888231b0eb30 RDI: ffff88823195b400
[ 93.742665] RBP: 0000000000001000 R08: 0000000000001ec0 R09: ffffffff81686c01
[ 93.744233] R10: ffffea0008c656c0 R11: 0000000000000040 R12: 0000000000001000
[ 93.745866] R13: ffff888231b0eb30 R14: 0000000000000000 R15: ffff888230f63700
[ 93.747438] FS: 0000000000000000(0000) GS:ffff888237b00000(0000) knlGS:0000000000000000
[ 93.749209] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.750540] CR2: ffffc90002e97be8 CR3: 000000021ce62006 C00000000000 DR1: 0000000000000000
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v6 12/20] kvm/vmx: Emulate MSR TEST_CTL
From: Xiaoyao Li @ 2019-04-08 8:54 UTC (permalink / raw)
To: Sean Christopherson, Fenghua Yu, Paolo Bonzini
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Dave Hansen, Ashok Raj, Peter Zijlstra, Kalle Valo, Michael Chan,
Ravi V Shankar, linux-kernel, x86, linux-wireless, netdev, kvm
In-Reply-To: <20190404144402.GA9911@linux.intel.com>
On Thu, 2019-04-04 at 07:44 -0700, Sean Christopherson wrote:
> On Wed, Apr 03, 2019 at 02:21:58PM -0700, Fenghua Yu wrote:
> > From: Xiaoyao Li <xiaoyao.li@linux.intel.com>
> >
> > A control bit (bit 29) in TEST_CTL MSR 0x33 will be introduced in
> > future x86 processors. When bit 29 is set, the processor causes #AC
> > exception for split locked accesses at all CPL.
> >
> > Please check the latest Intel 64 and IA-32 Architectures Software
> > Developer's Manual for more detailed information on the MSR and
> > the split lock bit.
> >
> > This patch emulate MSR TEST_CTL with vmx->msr_test_ctl and does the
> > following:
> > 1. As MSR TEST_CTL of guest is emulated, enable the related bits
> > in CORE_CAPABILITY to corretly report this feature to guest.
>
> s/corretly/correctly
will correct it. thanks.
> >
> > 2. Differentiate MSR TEST_CTL between host and guest.
> >
> > Signed-off-by: Xiaoyao Li <xiaoyao.li@linux.intel.com>
> > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > Acked-by: Paolo Bonzini <pbonzini@redhat.com>
> > ---
> > arch/x86/kvm/vmx/vmx.c | 35 +++++++++++++++++++++++++++++++++++
> > arch/x86/kvm/vmx/vmx.h | 1 +
> > arch/x86/kvm/x86.c | 17 ++++++++++++++++-
> > 3 files changed, 52 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index ab432a930ae8..309ccf593f0d 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -1663,6 +1663,12 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct
> > msr_data *msr_info)
> > u32 index;
> >
> > switch (msr_info->index) {
> > + case MSR_TEST_CTL:
> > + if (!msr_info->host_initiated &&
> > + !(vcpu->arch.core_capability & CORE_CAP_SPLIT_LOCK_DETECT))
> > + return 1;
> > + msr_info->data = vmx->msr_test_ctl;
> > + break;
> > #ifdef CONFIG_X86_64
> > case MSR_FS_BASE:
> > msr_info->data = vmcs_readl(GUEST_FS_BASE);
> > @@ -1797,6 +1803,14 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct
> > msr_data *msr_info)
> > u32 index;
> >
> > switch (msr_index) {
> > + case MSR_TEST_CTL:
> > + if (!(vcpu->arch.core_capability & CORE_CAP_SPLIT_LOCK_DETECT))
> > + return 1;
> > +
> > + if (data & ~TEST_CTL_ENABLE_SPLIT_LOCK_DETECT)
> > + return 1;
> > + vmx->msr_test_ctl = data;
> > + break;
> > case MSR_EFER:
> > ret = kvm_set_msr_common(vcpu, msr_info);
> > break;
> > @@ -4077,6 +4091,9 @@ static void vmx_vcpu_setup(struct vcpu_vmx *vmx)
> > ++vmx->nmsrs;
> > }
> >
> > + /* disable AC split lock by default */
> > + vmx->msr_test_ctl = 0;
> > +
> > vm_exit_controls_init(vmx, vmx_vmexit_ctrl());
> >
> > /* 22.2.1, 20.8.1 */
> > @@ -4114,6 +4131,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool
> > init_event)
> >
> > vmx->rmode.vm86_active = 0;
> > vmx->spec_ctrl = 0;
> > + vmx->msr_test_ctl = 0;
> >
> > vcpu->arch.microcode_version = 0x100000000ULL;
> > vmx->vcpu.arch.regs[VCPU_REGS_RDX] = get_rdx_init_val();
> > @@ -6313,6 +6331,21 @@ static void atomic_switch_perf_msrs(struct vcpu_vmx
> > *vmx)
> > msrs[i].host, false);
> > }
> >
> > +static void atomic_switch_msr_test_ctl(struct vcpu_vmx *vmx)
> > +{
> > + u64 host_msr_test_ctl;
> > +
> > + /* if TEST_CTL MSR doesn't exist on the hardware, do nothing */
> > + if (rdmsrl_safe(MSR_TEST_CTL, &host_msr_test_ctl))
> > + return;
>
> This adds a RDMSR on every VM-Enter, and a fault on CPUs that don't
> support MSR_TEST_CTL. Ideally the kernel would cache MSR_TEST_CTL and
> expose a helper that returns a boolean to indicate the existence of the
> MSRs along with the current value. Racing with split_lock_detect_store()
> is ok since this code runs with interrupts disabled, i.e. will block
> split_lock_detect_store() until after VM-Exit.
>
> Paolo, can you weigh in with your thoughts? I'm surprised you acked
> this patch given your earlier comment:
>
> https://patchwork.kernel.org/patch/10413779/#21892723
In v4 patchset, it checks boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) first in
atomic_switch_msr_test_ctl().
In v5 patchset, considering that there is another bit (bit 31) in MSR_TEST_CTL,
and !boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) cannot guarantee there is no
MSR_TEST_CTL in hardware. So I changed it to rdmsrl_safe() in v5.
It's my fault that I didn't point it out in the changelog in v5 patchset.
Considering the overhead of rdmsr every VMENTRY. I will use a percpu variable
msr_test_ctl_cache based on Thomas's comment to cache the value of host's
MSR_TEST_CTL.
> > +
> > + if (host_msr_test_ctl == vmx->msr_test_ctl)
> > + clear_atomic_switch_msr(vmx, MSR_TEST_CTL);
> > + else
> > + add_atomic_switch_msr(vmx, MSR_TEST_CTL, vmx->msr_test_ctl,
> > + host_msr_test_ctl, false);
> > +}
> > +
> > static void vmx_arm_hv_timer(struct vcpu_vmx *vmx, u32 val)
> > {
> > vmcs_write32(VMX_PREEMPTION_TIMER_VALUE, val);
> > @@ -6419,6 +6452,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
> >
> > atomic_switch_perf_msrs(vmx);
> >
> > + atomic_switch_msr_test_ctl(vmx);
> > +
> > vmx_update_hv_timer(vcpu);
> >
> > /*
> > diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
> > index a1e00d0a2482..6091a8b9de74 100644
> > --- a/arch/x86/kvm/vmx/vmx.h
> > +++ b/arch/x86/kvm/vmx/vmx.h
> > @@ -190,6 +190,7 @@ struct vcpu_vmx {
> > u64 msr_guest_kernel_gs_base;
> > #endif
> >
> > + u64 msr_test_ctl;
> > u64 spec_ctrl;
> >
> > u32 vm_entry_controls_shadow;
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 4459115eb0ec..e93c2f620cdb 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -1229,7 +1229,22 @@ EXPORT_SYMBOL_GPL(kvm_get_arch_capabilities);
> >
> > u64 kvm_get_core_capability(void)
> > {
> > - return 0;
> > + u64 data;
> > +
> > + rdmsrl_safe(MSR_IA32_CORE_CAPABILITY, &data);
> > +
> > + /* mask non-virtualizable functions */
> > + data &= CORE_CAP_SPLIT_LOCK_DETECT;
> > +
> > + /*
> > + * There will be a list of FMS values that have split lock detection
> > + * but lack the CORE CAPABILITY MSR. In this case, set
> > + * CORE_CAP_SPLIT_LOCK_DETECT since we emulate MSR CORE_CAPABILITY.
> > + */
> > + if (boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT))
> > + data |= CORE_CAP_SPLIT_LOCK_DETECT;
> > +
> > + return data;
> > }
> > EXPORT_SYMBOL_GPL(kvm_get_core_capability);
> >
> > --
> > 2.19.1
> >
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 02/12] drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
From: Maxime Ripard @ 2019-04-08 8:47 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Ondřej Jirman, linux-sunxi, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
open list:GPIO SUBSYSTEM
In-Reply-To: <CAGb2v65W_H5HrnY9+DuW-noshXLHgErJhEpHHhzcG15n1u=8iw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]
On Mon, Apr 08, 2019 at 03:28:24PM +0800, Chen-Yu Tsai wrote:
> On Mon, Apr 8, 2019 at 3:23 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Sat, Apr 06, 2019 at 01:45:04AM +0200, megous@megous.com wrote:
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected
> > > transistors, before it can be used. Model this as a power supply for DDC
> > > (via regulator framework).
> > >
> > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> >
> > The DDC bus itself is usually attached to the HDMI connector, so it
> > would make sense to make the supply also a property of the connector.
>
> I believe these are separate things. What this patch covers is power for
> a voltage shifter between the SoC and HDMI DDC pins. The HDMI connector's
> 5V supply to power the remote DDC chip is something else. And on the
> Orange Pi 3 they are indeed separate supplies.
Then maybe the endpoint link between the two would be the best place
to put this?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox