Hello,
I thought there would be some more comments coming and I could address
everything in one chunk. Not the case, besides your comments silence.
On 08.01.24 20:34, Christophe JAILLET wrote:
Hi,
a few nits below, should there be a v6.
I'm sure there will be but not so soon. Probably aft
applied to the s390 subsystem. This will go upstream with the next kernel merge
window.
Thanks
On 14.12.20 14:43, Zheng Yongjun wrote:
> Replace a comma between expression statements by a semicolon.
>
> Signed-off-by: Zheng Yongjun
> ---
> drivers/s390/crypto/zcrypt_cex4.c | 2 +-
> 1 file chan
applied to the s390 subsystem. This will go upstream with the next kernel merge
window.
Thanks
On 14.12.20 14:44, Zheng Yongjun wrote:
> Replace a comma between expression statements by a semicolon.
>
> Signed-off-by: Zheng Yongjun
> ---
> drivers/s390/crypto/zcrypt_cex2a.c | 2 +-
> 1 file cha
red by the function pkey_genprotkey()
which is
called just 2 lines above. An internal function the module should trust here. I
don't think
there is an additional length check needed here.
However, Thanks for your contribution.
Harald Freudenberger
see this function calls another function in the very same file and
fio_ap driver to do a bulk
>> plug of all affected adapters, domains and control domains into
>> affected guests rather than plugging them one at a time when the
>> probe callback is invoked.
>>
>> Please note that changes to the apmask and aqmask do not tri
/dmar.o]
Error 1
make[2]: *** [scripts/Makefile.build:500: drivers/iommu/intel] Error 2
make[1]: *** [scripts/Makefile.build:500: drivers/iommu] Error 2
make: *** [Makefile:1799: drivers] Error 2
--
Hilsen Harald
that changes to the apmask and aqmask do not trigger
> these two callbacks since the bus scan function is not invoked by changes
> to those masks.
>
> Signed-off-by: Harald Freudenberger
Did I really sign-off this ? I know, I saw this code but ...
First of all, please separate the ap
iver)
> @@ -293,6 +294,9 @@ void ap_queue_init_state(struct ap_queue *aq);
> struct ap_card *ap_card_create(int id, int queue_depth, int raw_device_type,
> int comp_device_type, unsigned int functions);
>
> +#define APMASKSIZE (BITS_TO_LONGS(AP_DEVICES) * sizeof(unsigned long))
> +#define AQMASKSIZE (BITS_TO_LONGS(AP_DOMAINS) * sizeof(unsigned long))
> +
> struct ap_perms {
> unsigned long ioctlm[BITS_TO_LONGS(AP_IOCTLS)];
> unsigned long apm[BITS_TO_LONGS(AP_DEVICES)];
I still don't like this code. That's because of what it is doing - not because
of the code quality.
And Halil, you are right. It is adding more pressure to the mutex used for
locking the apmask
and aqmask stuff (and the zcrypt multiple device drivers support code also).
I am very concerned about the in_use callback which is called with the
ap_perms_mutex
held AND during bus_for_each_drv (so holding the overall AP BUS mutex) and then
diving
into the vfio_ap ... with yet another mutex to protect the vfio structs.
Reviewed-by: Harald Freudenberger
Linus Torvalds [28.09.2020 18:22]:
> On Mon, Sep 28, 2020 at 7:07 AM Harald Arnesen wrote:
>>
>> I will try bisecting if no-one has a simple explanation.
>
> There's a simple explanation, no need to bisect.
>
> I'll push out the fix asap,
Everything is OK now.
Thanks!
--
Hilsen Harald
Harald
[0.00] microcode: microcode updated early to revision 0x2f, date =
2019-02-17
[0.00] Linux version 5.9.0-rc7 (harald@catnip) (gcc (GCC) 10.2.0, GNU
ld (GNU Binutils) 2.34) #9 SMP PREEMPT Mon Sep 28 12:31:22 CEST 2020
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz
:00:00 2001
From: Harald Freudenberger
Date: Thu, 10 Sep 2020 11:32:43 +0200
Subject: [PATCH] s390/zcrypt: remove set_fs() invocation in zcrypt device
driver
This patch reworks the zcrypt device driver so that the set_fs()
invocation is not needed any more. Instead there is a new flag bool
usersp
On 11.09.20 08:21, Christoph Hellwig wrote:
> On Thu, Sep 10, 2020 at 12:28:38PM +0200, Harald Freudenberger wrote:
>> +static inline unsigned long z_copy_from_user(bool userspace,
>> + void *to, const void __user *from,
>> unsigned lo
z_copy_from_user() and z_copy_to_user() which either
invoke copy_from_user (userspace is true) or memcpy (userspace is
false) the zcrypt dd and the AP bus now has no requirement for
the set_fs() functionality any more.
Signed-off-by: Harald Freudenberger
---
drivers/s390/crypto/zcrypt_api.c | 30
Linus Torvalds [08.09.2020 20:19]:
> On Fri, Sep 4, 2020 at 2:51 PM Harald Arnesen wrote:
>>
>> Still doesn't work without the three reverts
>> (763fedd6a216, 9e0f9464e2ab, 7ac2d2536dfa)...
>
> So this didn't make rc4, but it's in my tree now.
>
>
915 display fixes.
>
> Any movement on the i915 relocation issue? I've only seen the one
> report for the 64-bit case, but clearly there was more going on than
> just the missing page table flush on 32-bit..
Still doesn't work without the three reverts
(763fedd6a216, 9e0f9464e2ab, 7ac2d2536dfa)...
--
Hilsen Harald
Still (rc3) doesn't work without the three reverts.
I'm not sure how to proceed, I cannot capture any oops, and see nothing
obvious in any logs.
--
Hilsen Harald
Dave Airlie [26.08.2020 22:47]:
> On Thu, 27 Aug 2020 at 06:44, Harald Arnesen wrote:
>>
>> Linus Torvalds [26.08.2020 20:04]:
>>
>> > On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote:
>> >> Somehow related to lightdm or xfce4? However, it is
Linus Torvalds [26.08.2020 20:04]:
> On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote:
>> Somehow related to lightdm or xfce4? However, it is a regression, since
>> kernel 5.8 works.
> Yeah, apparently there's something else wrong with the relocation changes too.
&g
Harald Arnesen [26.08.2020 10:36]:
> I was wrong about ssh working. The whole machine locks up when X starts.
>
> A strange thing, sometimes I can log in from lightdm before it locks up,
> sometimes I cannot even use the login screen. Timing related?
>
> If I don't start
Linus Torvalds [25.08.2020 20:19]:
> On Tue, Aug 25, 2020 at 9:32 AM Harald Arnesen wrote:
>>
>> > For posterity, I'm told the fix is [1].
>> >
>> > [1]
>> > https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/
>>
>
ou get any oops or other indication of what ends up going wrong?
> Since ssh works that should be fairly easy to see.
Away from the machine now, will check tomorrow morning (CET).
--
Hilsen Harald
].
>
> BR,
> Jani.
>
>
> [1] https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/
Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard
freeezes. I can still ssh into the machine
The three reverts (763fedd6a216, 7ac2d2536dfa and 9e0f9464e2ab) fixes
the bug for me.
--
Hilsen Harald
On Tue, Aug 25, 2020 at 06:13:41PM +0800, Kenneth Chan wrote:
> Take over maintaniership of panasonic-laptop from Harald Welte.
>
>
> Signed-off-by: Kenneth Chan
Acked-by: Harald Welte
--
- Harald Weltehttp://laforge.
Dear Keneth and Linux kernel developers,
as I have discontinued maintenance of the panasonic-laptop driver (and
recently sent a related MAINTAINERS update to that fact), I would like
to suggest Kenneth as the new maintainer for this driver.
Regards,
Harald
--
- Harald Welte
On 02.08.20 13:15, Tianjia Zhang wrote:
> In the first place, the initialization value of `rc` is wrong.
> It is unnecessary to initialize `rc` variables, so remove their
> initialization operation.
>
> Fixes: f2bbc96e7cfad ("s390/pkey: add CCA AES cipher key support")
&
Kalle Valo [13.05.2020 17:31]:
> Great, so it's not a problem due to my setup.
I see the same thing on two machines, using a self-compiled gcc 10.1.0.
Glad to hear it's not just me. Switched back to 9.3.0 for the time being.
--
Hilsen Harald
On 29.04.20 00:30, Tony Krowiak wrote:
>
>
> On 4/28/20 6:57 AM, Harald Freudenberger wrote:
>> On 28.04.20 12:07, Halil Pasic wrote:
>>> On Mon, 27 Apr 2020 17:48:58 -0400
>>> Tony Krowiak wrote:
>>>
>>>> On 4/27/20 11:17 AM, Halil
On 28.04.20 00:24, Tony Krowiak wrote:
>
>
> On 4/27/20 4:20 AM, Pierre Morel wrote:
>>
>>
>> On 2020-04-07 21:20, Tony Krowiak wrote:
>>> Introduces a new driver callback to prevent a root user from unbinding
>>> an AP queue from its device driver if the queue is in use. The intent of
>>> this cal
On 28.04.20 12:07, Halil Pasic wrote:
> On Mon, 27 Apr 2020 17:48:58 -0400
> Tony Krowiak wrote:
>
>>
>> On 4/27/20 11:17 AM, Halil Pasic wrote:
>>> On Mon, 27 Apr 2020 15:05:23 +0200
>>> Harald Freudenberger wrote:
>>>
>>>> On 24.04.
On 27.04.20 17:17, Halil Pasic wrote:
> On Mon, 27 Apr 2020 15:05:23 +0200
> Harald Freudenberger wrote:
>
>> On 24.04.20 05:57, Halil Pasic wrote:
>>> On Tue, 7 Apr 2020 15:20:01 -0400
>>> Tony Krowiak wrote:
>>>
>>>> Rather than l
s the Schilling/OpenSolaris shell that is the problem, not
that I use it anyway.
--
Hilsen Harald
annot find a way to satisfy everybody.
>
I'm totally fine with the way it is now, now that I know how it works.
However, doesn't Posix dictate that there is a /bin/sh?
--
Hilsen Harald
Harald Arnesen [05.10.2019 11:03]:
> Masahiro Yamada [05.10.2019 05:24]:
>
>> I cannot reproduce it.
>>
>> I tested bindeb-pkg for the latest Linus tree successfully.
>
> Strange, I have now tried another machine running the same distro
> (Devuan Beowulf), and
Masahiro Yamada [05.10.2019 05:24]:
> I cannot reproduce it.
>
> I tested bindeb-pkg for the latest Linus tree successfully.
Strange, I have now tried another machine running the same distro
(Devuan Beowulf), and I get the same result there. Will check further.
--
Hilsen Harald
ce package linux-5.4.0-rc1-00014-gcc3a7bfe62b9
dpkg-buildpackage: info: source version 5.4.0-rc1-00014-gcc3a7bfe62b9-1
dpkg-buildpackage: info: source distribution beowulf
dpkg-buildpackage: info: source changed by Harald Arnesen
dpkg-architecture: warning: specified GNU system type x86_64-linux-gn
Am 17.09.19 um 18:23 schrieb Linus Torvalds:
> I do agree that a message is a good idea regardless, but I don't think
> it necessarily solves the problems except for developers
sadly in our current world dvelopers and maintainers don't read any logs
and as long it compiles and boots it works an
Am 10.09.19 um 19:33 schrieb Ahmed S. Darwish:
> Yes, doing any of below steps makes the problem reliably disappear:
>
> - boot param "random.trust_cpu=on"
> - rngd(8) enabled at boot (entropy source: x86 RDRAND + jitter)
> - pressing random 3 or 4 keyboard keys while GDM boot is stuck
a
Am 04.09.19 um 14:58 schrieb Theodore Y. Ts'o:
> Again, the likelihood that there will be file systems that have this
> problem in 2038 is... extremely low in my judgement. Storage media
> just doesn't last that long
in times of virtualization storage media are below the vdisk and the
file sys
Am 03.09.19 um 23:17 schrieb Theodore Y. Ts'o:
> I know of a truly vast number of servers in production all over the
> world which are using 128 byte inodes, and spamming the inodes at the
> maximum rate limit is a really bad idea. This includes at some major
> cloud data centers where the life
that's still not in 5.2.8
without the exception and "nf_conntrack_tcp_timeout_max_retrans = 60" a
vnc-over-ssh session having the VNC view in the background freezes
within 60 secods
---
IPV4 TABLE MANGLE (
r KVM code. However, never used.
So removing the export is the right thing. Thanks Denis
Heiko/Vasily will you pick this patch please?
Reviewed-by: Harald Freudenberger
On 17.06.19 17:07, Tony Krowiak wrote:
> On 6/17/19 6:05 AM, Harald Freudenberger wrote:
>> On 13.06.19 21:39, Tony Krowiak wrote:
>>> The AP architecture does not preclude assignment of AP resources that are
>>> not available. Let's go ahead and implement this face
On 13.06.19 21:39, Tony Krowiak wrote:
> This patch updates the vfio-ap documentation to include the information
> below.
>
> Changes made to the mdev matrix assignment interfaces:
>
> * Allow assignment of APQNs that are not bound to the vfio-ap device
> driver as long as they are not owned by a
On 13.06.19 21:39, Tony Krowiak wrote:
> The AP architecture does not preclude assignment of AP resources that are
> not available. Let's go ahead and implement this facet of the AP
> architecture for linux guests.
>
> The current implementation does not allow assignment of AP adapters or
> domains
On 13.06.19 21:39, Tony Krowiak wrote:
> Introduces a new driver callback to prevent a root user from unbinding
> an AP queue from its device driver if the queue is in use. This prevents
> a root user from inadvertently taking a queue away from a guest and
> giving it to the host, or vice versa. Th
On 13.06.19 21:39, Tony Krowiak wrote:
> Refactors the AP queue reset function to wait until the queue is empty
> after the PQAP(ZAPQ) instruction is executed to zero out the queue as
> required by the AP architecture.
>
> Signed-off-by: Tony Krowiak
> ---
> drivers/s390/crypto/vfio_ap_ops.c | 49
On 13.06.19 21:39, Tony Krowiak wrote:
> In order to limit the number of private mdev functions called from the
> vfio_ap device driver as well as to provide a landing spot for dynamic
> configuration code related to binding/unbinding AP queue devices to/from
> the vfio_ap driver, the following cha
n Control */
> 156, /* etoken facility */
> -1 /* END */
> }
acked-by: Harald Freudenberger
v->kvm->arch.crypto.pqap_hook = NULL;
> + vfio_ap_mdev_reset_queues(mdev);
> + kvm_put_kvm(matrix_mdev->kvm);
> + matrix_mdev->kvm = NULL;
> + }
> + mutex_unlock(&matrix_dev->lock);
>
> - vfio_ap_mdev_reset_queues(mdev);
> vfio_unregister_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY,
>&matrix_mdev->iommu_notifier);
> vfio_unregister_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
>&matrix_mdev->group_notifier);
> - matrix_mdev->kvm = NULL;
> module_put(THIS_MODULE);
> }
>
> @@ -941,6 +1263,7 @@ static ssize_t vfio_ap_mdev_ioctl(struct mdev_device
> *mdev,
> {
> int ret;
>
> + mutex_lock(&matrix_dev->lock);
> switch (cmd) {
> case VFIO_DEVICE_GET_INFO:
> ret = vfio_ap_mdev_get_device_info(arg);
> @@ -952,6 +1275,7 @@ static ssize_t vfio_ap_mdev_ioctl(struct mdev_device
> *mdev,
> ret = -EOPNOTSUPP;
> break;
> }
> + mutex_unlock(&matrix_dev->lock);
>
> return ret;
> }
> diff --git a/drivers/s390/crypto/vfio_ap_private.h
> b/drivers/s390/crypto/vfio_ap_private.h
> index 18dcc4d..f46dde5 100644
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -4,6 +4,7 @@
> *
> * Author(s): Tony Krowiak
> * Halil Pasic
> + * Pierre Morel
> *
> * Copyright IBM Corp. 2018
> */
> @@ -89,5 +90,15 @@ struct ap_matrix_mdev {
>
> extern int vfio_ap_mdev_register(void);
> extern void vfio_ap_mdev_unregister(void);
> +int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi,
> + unsigned int retry);
>
> +struct vfio_ap_queue {
> + struct ap_matrix_mdev *matrix_mdev;
> + unsigned long saved_pfn;
> + int apqn;
> +#define VFIO_AP_ISC_INVALID 0xff
> + unsigned char saved_isc;
> +};
> +struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q);
> #endif /* _VFIO_AP_PRIVATE_H_ */
acked-by: Harald Freudenberger
be1..18dcc4d 100644
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -81,8 +81,10 @@ struct ap_matrix_mdev {
> struct list_head node;
> struct ap_matrix matrix;
> struct notifier_block group_notifier;
> + struct notifier_block iommu_notifier;
> struct kvm *kvm;
> struct kvm_s390_module_hook pqap_hook;
> + struct mdev_device *mdev;
> };
>
> extern int vfio_ap_mdev_register(void);
acked-by: Harald Freudenberger
(struct kvm_vcpu *vcpu)
> {
> int rc;
> @@ -878,6 +962,8 @@ int kvm_s390_handle_b2(struct kvm_vcpu *vcpu)
> return handle_sthyi(vcpu);
> case 0x7d:
> return handle_stsi(vcpu);
> + case 0xaf:
> + return handle_pqap(vcpu);
> case 0xb1:
> return handle_stfl(vcpu);
> case 0xb2:
> diff --git a/drivers/s390/crypto/vfio_ap_private.h
> b/drivers/s390/crypto/vfio_ap_private.h
> index 76b7f98..a910be1 100644
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ap_bus.h"
>
> @@ -81,6 +82,7 @@ struct ap_matrix_mdev {
> struct ap_matrix matrix;
> struct notifier_block group_notifier;
> struct kvm *kvm;
> + struct kvm_s390_module_hook pqap_hook;
> };
>
> extern int vfio_ap_mdev_register(void);
acked-by: Harald Freudenberger
x/of_gpio.h"
>
> Signed-off-by: Shobhit Kukreti
Acked-by: Harald Geyer
> ---
> drivers/iio/humidity/dht11.c | 28 ++--
> 1 file changed, 10 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/iio/humidity/dht11.c b/drivers/iio/humidity/dht
ers with class_find_device() users.
>
> Cc: Alexander Shishkin
> Cc: Wolfram Sang
> Cc: Jonathan Cameron
> Cc: Hartmut Knaack
> Cc: Grygorii Strashko
> Cc: "David S. Miller"
> Cc: Bjorn Helgaas
> Cc: Sebastian Ott
> Cc: Peter Oberparleiter
> Cc: Hara
On 03.06.19 17:50, Suzuki K Poulose wrote:
> Use the generic helper to find a device matching the devt.
>
> Cc: Harald Freudenberger
> Cc: Heiko Carstens
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/s390/crypto/zcrypt_api.c | 11 +--
> 1 file changed, 1 in
On 03.06.19 17:49, Suzuki K Poulose wrote:
> Use the new class_find_device_by_name() helper.
>
> Cc: Harald Freudenberger
> Cc: Martin Schwidefsky
> Cc: Heiko Carstens
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/s390/crypto/zcrypt_api.c | 12 ++--
> 1
gt; Thanks for the pointer.
> So the preferred way is defining a new crypto algorithm prefixed with
> "p" and reusing setkey to provide the key reference.
The "p" in paes is because we call it "protected key aes". I think you are not
limited
to the "p". What Herbert tries to point out is that you may define your own
cipher with an unique name and there you can handle your secure key references
as you like. You may use the s390 paes implementation as a starting point.
regards Harald Freudenberger
>
> Thanks,
> //richard
>
ng to load the pkey module because of missing HW functionality.
>
> Cc: Harald Freudenberger
> Cc: Heiko Carstens
> Cc: Cornelia Huck
> Cc: Christian Borntraeger
> Signed-off-by: David Hildenbrand
> ---
> drivers/s390/crypto/pkey_api.c | 6 +++---
> 1 file changed, 3 inse
Takashi Iwai [18.04.2019 09:38]:
> Hi,
>
> we've got a regression report on the recent 5.0.x kernel, starting
> from 5.0.6, where Windows XP can't boot on KVM any longer.
Not for all configurations. I just checked with 5.0.8, and Windows XP
boots just fine on KVM.
--
Hilsen Harald
bugzilla.suse.com/show_bug.cgi?id=1132694
>>
>> Is there already a followup fix? If not, we need to revert it from
>> stable, at least.
>
> Is this also a problem in 5.1-rc5?
My previously installed Windows XP boots and runs fine in 5.1-rc5.
--
Hilsen Harald
On 11.04.19 23:03, Tony Krowiak wrote:
> Once an APQN is assigned to an mdev device it will remained assigned until
> it is explicitly unassigned from the mdev device. The associated AP queue
> devices, however, can come and go due to failures or deliberate actions by
> a sysadmin. For example, a s
On 11.04.19 23:03, Tony Krowiak wrote:
> Introduces a new driver callback to prevent a root user from unbinding
> an AP queue from its device driver if the queue is in use. This prevents
> a root user from inadvertently taking a queue away from a guest and
> giving it to the host, or vice versa. Th
func_code = -1;
> rc = -EFAULT;
> goto out_free;
> }
Thanks Arnd, but as Nathan already wrote, I'd prefer to have the
variable initialized with 0 instead of -1.
If you agree with this, I'll rewrite the patch and apply it to our
internal git and it will appear at kernel org with the next s390 code merge
then.
regards Harald Freudenberger
made.
Regards,
Harlad
--
- Harald Weltehttp://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
On 26.03.19 21:45, Tony Krowiak wrote:
> On 3/22/19 10:43 AM, Pierre Morel wrote:
>> The AP interruptions are assigned on a queue basis and
>> the GISA structure is handled on a VM basis, so that
>> we need to add a structure we can retrieve from both side
>
> s/side/sides/
>
>> holding the informa
On 22.03.19 15:43, Pierre Morel wrote:
> The AP interruptions are assigned on a queue basis and
> the GISA structure is handled on a VM basis, so that
> we need to add a structure we can retrieve from both side
> holding the information we need to handle PQAP/AQIC interception
> and setup the GISA.
Hi Pavel,
On 3/7/19 12:10 AM, Pavel Machek wrote:
On Tue 2019-01-22 11:15:39, Harald Dunkel wrote:
Is this the wrong list to report this problem? I haven't found a
"mem" mailing list on vger.
Right list, ugly looking problem. How reproducible is it?
By now this was just a
On 30.01.19 19:32, Sebastian Ott wrote:
> On Wed, 30 Jan 2019, Tony Krowiak wrote:
>> +#if IS_ENABLED(CONFIG_ZCRYPT)
>> +void ap_bus_cfg_chg(void);
>> +#else
>> +#error "no CONFIG_ZCRYPT"
>^
> I don't think that's the right thing to do here.
>
>
>> +++ b/drivers/s390/cio/chsc.h
>> @@ -9,6 +9,7
On 21.02.19 08:37, Christian Borntraeger wrote:
>
> On 20.02.2019 14:12, Harald Freudenberger wrote:
>> On 18.02.19 19:08, Pierre Morel wrote:
>>> Libudev relies on having a subsystem link for non-root devices. To
>>> avoid libudev (and potentially other userspace to
};
>
> extern struct ap_matrix_dev *matrix_dev;
You are introducing a new bus just for a user space application which is unable
to deal with a device directly attached to the root of devices ? So you are
fixing
kernel code because of disability of userspace code. Hm, you are switching
root cause and effect. However, not my job.
Why do you need this dummy bus ? Did you evaluate using a "class" subsystem
instead ? This is very common and my assumption is that libudev is able to
handle
this. I am using a "zcrypt" class for providing additional zcrypt device nodes
and
this works fine together with udev. I would avoid the introduction and
maintenance
of bus code at any cost.
Btw. having a look onto the naming ... the module is named "vfio_ap", the
driver is named "vfio_ap", the bus is named "vfio_ap", the root bus device is
named "vfio_ap" ... a bunch of vfio_aps naming different things.
regards
Harald Freudenberger
On 01.02.19 15:35, Cornelia Huck wrote:
> On Thu, 31 Jan 2019 18:50:57 -0500
> Tony Krowiak wrote:
>
>> On 1/31/19 4:55 AM, Cornelia Huck wrote:
>>> On Wed, 30 Jan 2019 12:48:46 -0500
>>> Tony Krowiak wrote:
>>> Two questions:
>>> - Does the event cover _any_ change to the AP configuration, or ca
t;
As Martin already pointed out the ap bus code is statically build into the
kernel
with this line in the Makefile:
obj-$(subst m,y,$(CONFIG_ZCRYPT)) += ap.o
So CONFIG_ZCRYPT may have the value 'm' or 'y'
and this is also the reason why a simple #ifdef CONFIG_ZCRYPT does not
work, instead #if IS_ENABLED(CONFIG_ZCRYPT) has to be used.
Only the ap stuff (which is: ap_bus.o, ap_card.o and ap_queue.o) is statically
build into the kernel. The zcrypt kernel module is loaded as a dependency
when a crypto card is detected. So detecting a CEX4 forces kernel module
zcrypt_cex4.ko which forces the zcrypt.ko to insert into the kernel.
So all global functions in ap_bus.c are available when CONFIG_ZCRYPT is
enabled. However, I thought the symbol still needs an EXPORT_SYMBOL()
statement. Otherwise I should throw out all these statements.
Harald
Is this the wrong list to report this problem? I haven't found a
"mem" mailing list on vger.
Regards
Harri
-
On 1/14/19 2:01 PM, Harald Dunkel wrote:
Hi folks,
my server stumbled over this last night:
Sean Christopherson [14.01.2019 19:33]:
> On Mon, Jan 14, 2019 at 06:04:27PM +0100, Harald Arnesen wrote:
>> Qemu with KVM acceleration fails with kernel 5.0-rc1 and 5.0-rc2.
>> It works fine with 4.20.
> Can you test the attached patch? Found a bug when re-inspecting the
&g
Hi folks,
my server stumbled over this last night:
Jan 13 19:03:15 sylvester kernel: [272280.820190] BUG: unable to handle kernel
paging request at 1008
Jan 13 19:03:15 sylvester kernel: [272280.820198] PGD 0 P4D 0
Jan 13 19:03:15 sylvester kernel: [272280.820203] Oops: [#1] PR
gt; +
>> + Control domains can similarly be assigned using the
>> assign_control_domain
>> + sysfs file.
>> +
>> + If a mistake is made configuring an adapter, domain or control domain,
>> + you can use the unassign_xxx files to unassign the adapter, domain or
>> + control domain.
>> +
>> + To display the matrix configuration for Guest1:
>> +
>> + cat matrix
>> +
>> + This is how the matrix is configured for Guest2:
>> +
>> + echo 5 > assign_adapter
>> + echo 0x47 > assign_domain
>> + echo 0xff > assign_domain
>> +
>> + This is how the matrix is configured for Guest3:
>> +
>> + echo 6 > assign_adapter
>> + echo 0x47 > assign_domain
>> + echo 0xff > assign_domain
>> +
> I'm curious why this interface didn't adopt the +/- notation invented
> above for consistency. Too difficult to do rollbacks with a string on
> entries?
>
> Looks pretty reasonable other than the points of confusion noted.
> Thanks,
>
> Alex
>
Hello Alex
the AP bus apmask and aqmask interface is not part of this patch series.
It's a general concept not only related to KVM and vfio but may be used
(and will) by other kernel and userspace features.
The bit ordering follows other implementations in the s390 (big endian)
realm where bit counting starts with 0 on the very left side and increases to
the right. All the AP bus stuff obeys to this (maybe historical) scheme.
Please have a look on the patches which introduced this mask API:
- s390/zcrypt: AP bus support for alternate driver(s) :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e0bdbe5c21cb8316a694e46ad5aad339f6894a6
- s390/zcrypt: hex string mask improvements for apmask and aqmask:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3d8f60d38e249f989a7fca9c2370c31c3d5487e1
The patch headers should describe the behavior and the syntax
of the recognized string patterns in more detail.
regards
Harald Freudenberger (maintainer of the s390 AP bus and zcrypt device driver
code)
On 24.09.2018 14:16, Halil Pasic wrote:
>
> On 09/24/2018 01:36 PM, Cornelia Huck wrote:
>> On Wed, 12 Sep 2018 15:43:03 -0400
>> Tony Krowiak wrote:
>>
>>> From: Tony Krowiak
>>>
>>> Let's call PAPQ(ZAPQ) to zeroize a queue for each queue configured
>>> for a mediated matrix device when it is re
On 21.09.2018 11:40, Cornelia Huck wrote:
> On Wed, 12 Sep 2018 15:42:56 -0400
> Tony Krowiak wrote:
>
>> From: Tony Krowiak
>>
>> Introduces two new sysfs attributes for the VFIO mediated
>> matrix device for assigning AP adapters to and unassigning
>> AP adapters from a mediated matrix device.
On 05.09.2018 02:16, Kees Cook wrote:
> On Fri, Aug 24, 2018 at 12:42 AM, Martin Schwidefsky
> wrote:
>> Harald Freudenberger (5):
>> s390/zcrypt: hex string mask improvements for apmask and aqmask.
> This (and an earlier 2017 commit) adds VLAs, which are being
> re
have an empty control domain mask
and the guest should be able to run crypto CPRBs on the usage domain(s) without
any problems. However, nobody has tried this.
regards
Harald Freudenberger
On 21.08.2018 17:53, Cornelia Huck wrote:
> On Tue, 21 Aug 2018 11:00:00 +0200
> Harald Freudenberger wrote:
>
>> On 20.08.2018 18:03, Cornelia Huck wrote:
>>> On Mon, 13 Aug 2018 17:48:19 -0400
>>> Tony Krowiak wrote:
>>>> +* AP Instructions:
&
On 20.08.2018 18:03, Cornelia Huck wrote:
> On Mon, 13 Aug 2018 17:48:19 -0400
> Tony Krowiak wrote:
>
>> From: Tony Krowiak
>>
>> This patch provides documentation describing the AP architecture and
>> design concepts behind the virtualization of AP devices. It also
>> includes an example of how
.
-
>From 9e050f843f3281da1f65292422e30f2dd1fd6d98 Mon Sep 17 00:00:00 2001
From: Harald Freudenberger
Date: Thu, 9 Aug 2018 11:59:34 +0200
Subject: [PATCH] s390/zcrypt: fix ap_instructions_available() returncodes
During review of KVM patches it was complained that the
ap_instructions_availa
On 10.08.2018 10:49, Cornelia Huck wrote:
> On Thu, 9 Aug 2018 12:06:56 -0400
> Tony Krowiak wrote:
>
>> On 08/09/2018 05:17 AM, Harald Freudenberger wrote:
>>> On 09.08.2018 11:06, Cornelia Huck wrote:
>>>> On Wed, 8 Aug 2018 10:44:14 -0400
>>>>
Here is now a reworked version of the integrate ap_asm.h into include/asm/ap.h
patch
which can be used to apply it within the AP virtualisation patch queue for
testing:
>From c81710e7cd073c4f9a904f3539ecf17fd89c9c2d Mon Sep 17 00:00:00 2001
From: Harald Freudenberger
Date: Tue, 12 Jun 2018
On 09.08.2018 11:06, Cornelia Huck wrote:
> On Wed, 8 Aug 2018 10:44:14 -0400
> Tony Krowiak wrote:
>
>> From: Harald Freudenberger
>>
>> Move all the inline functions from the ap bus header
>> file ap_asm.h into the in-kernel api header file
>> arch/s39
On 09.08.2018 10:17, David Hildenbrand wrote:
> On 08.08.2018 16:44, Tony Krowiak wrote:
>> From: Tony Krowiak
>>
>> Introduces a new CPU model feature and two CPU model
>> facilities to support AP virtualization for KVM guests.
>>
>> CPU model feature:
>>
>> The KVM_S390_VM_CPU_FEAT_AP feature in
@ -1242,7 +1242,7 @@ static int __init ap_module_init(void)
>
> /* Create /sys/devices/ap. */
> ap_root_device = root_device_register("ap");
> - rc = PTR_RET(ap_root_device);
> + rc = PTR_ERR_OR_ZERO(ap_root_device);
> if (rc)
> goto out_bus;
>
Reviewed-by: Harald Freudenberger
sure there won't be more than a couple of weeks of
> sunshine in the UK this summer.
>
> That's what you were trying to say, right?
>
> Linus
FYI: Northern Europe has been exceptionally warm this summer.
--
Hilsen Harald
On 09.07.2018 16:17, Pierre Morel wrote:
> On 29/06/2018 23:11, Tony Krowiak wrote:
>> Registers the matrix device created by the VFIO AP device
>> driver with the VFIO mediated device framework.
>> Registering the matrix device will create the sysfs
>> structures needed to create mediated matrix d
On 03.07.2018 16:56, Tony Krowiak wrote:
> On 07/03/2018 03:46 AM, Harald Freudenberger wrote:
>> On 02.07.2018 18:28, Halil Pasic wrote:
>>>
>>> On 06/29/2018 11:11 PM, Tony Krowiak wrote:
>>>> This patch provides documentation describing the AP architect
On 29.06.2018 23:11, Tony Krowiak wrote:
> This patch provides documentation describing the AP architecture and
> design concepts behind the virtualization of AP devices. It also
> includes an example of how to configure AP devices for exclusive
> use of KVM guests.
>
> Signed-off-by: Tony Krowiak
On 02.07.2018 18:28, Halil Pasic wrote:
>
>
> On 06/29/2018 11:11 PM, Tony Krowiak wrote:
>> This patch provides documentation describing the AP architecture and
>> design concepts behind the virtualization of AP devices. It also
>> includes an example of how to configure AP devices for exclusive
>
t; I'll check with the developer.
The proposal is out on the internal mailing list. I'd like to release it
(internal) tomorrow or start
next week. Already talked with Christian about this because we need to align it
somehow with
kvm and s390 kernel development.
regards
Haral
the network stack, or
b) not use the existing tables/chains with their pre-defined semantics
but rather start new 'tables' which can then have different semantics
as defined at the time of their implementation.
My apologies if I misunderstood something about bpfilter. Feel free t
ric kernel interface for some kind
of key token as a binary blob. I am also open to use the kernel key
ring for future extensions. But please understand we needed a way
to support our hardware keys and I think the chosen design isn't
so bad.
regards Harald Freudenberger
using the kernel key ring in future extensions.
Maxime Ripard writes:
> On Thu, Mar 15, 2018 at 04:25:10PM +0000, Harald Geyer wrote:
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + capslock {
> > + label = "leds:green:capslock";
>
> The
Hi Jia-Ju Bai,
On Sun, Mar 18, 2018 at 10:49:57PM +0800, Jia-Ju Bai wrote:
> This is found by a static analysis tool named DCNS written by myself.
nice catch!
> Signed-off-by: Jia-Ju Bai
Acked-by: Harald Welte
--
- Harald Weltehttp://laforge.gnumon
ments in kernel source code), hence:
Acked-by: Harald Welte
--
- Harald Weltehttp://laforge.gnumonks.org/
"Privacy in residential applications is a desira
Hi,
afzal mohammed writes:
> On Mon, Mar 12, 2018 at 04:10:45PM +0000, Harald Geyer wrote:
> > This series adds support for the TERES I open hardware laptop produced
> > by olimex. With these patches and a bootloader capable of setting up
> > simple framebuffer the la
.
Patch 5 finally adds the board dts itself.
Changes to the previous version are listed along the individual patches.
best regards,
Harald
Harald Geyer (5):
arm64: dts: allwinner: a64: Add i2c0 pins
arm64: dts: allwinner: a64: Add watchdog
arm64: dts: allwinner: a64: add simplefb for A64 SoC
1 - 100 of 389 matches
Mail list logo
