From: Tony Krowiak <akrowiak@linux.vnet.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, freude@de.ibm.com, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com, borntraeger@de.ibm.com,
kwankhede@nvidia.com, bjsdjshi@linux.vnet.ibm.com,
pbonzini@redhat.com, alex.williamson@redhat.com,
pmorel@linux.vnet.ibm.com, alifm@linux.vnet.ibm.com,
mjrosato@linux.vnet.ibm.com, qemu-s390x@nongnu.org,
jjherne@linux.vnet.ibm.com, thuth@redhat.com,
pasic@linux.vnet.ibm.com
Subject: Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver
Date: Tue, 14 Nov 2017 11:37:05 -0500 [thread overview]
Message-ID: <06ddee4e-e1b8-ba17-5e3e-241e4dcf7cd0@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171114134040.3fcd6efd.cohuck@redhat.com>
On 11/14/2017 07:40 AM, Cornelia Huck wrote:
> On Fri, 13 Oct 2017 13:38:50 -0400
> Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote:
>
>> Introduces a new AP matrix device driver. This device driver
>> will ultimately perform the following functions:
>>
>> * Register with the AP bus to let it know that the matrix
>> driver can control AP queue devices. This will allow
>> an administrator to unbind an AP queue device from its
>> device driver and bind it to the matrix device driver.
>> This is how AP queue devices will be reserved for use
>> by guest machines.
>>
>> * Register the matrix device created by the AP matrix bus
>> with the VFIO mediated device framework. This will create
>> the sysfs entries needed to create mediated matrix devices.
>> Each mediated matrix device can be configured with a matrix
>> of adapters, usage domains and control domains that can be
>> accessed by a guest machine.
>>
>> * Process requests via ioctl calls defined for the mediated
>> matrix device. The guest can access the ioctl calls via
>> the mediated device's file descriptor to:
>>
>> * Grant access to the adapters, usage domains and
>> control domains configured for the mediated matrix
>> device.
>>
>> This device driver
>> is built on the VFIO mediated device framework. The VFIO mediated
>> device framework allows a mediated device to be dedicated exclusively
>> to a single guest VM.
>>
>> Signed-off-by: Tony Krowiak <akrowiak@linux.vnet.ibm.com>
>> ---
>> MAINTAINERS | 2 +
>> arch/s390/Kconfig | 13 +++
>> arch/s390/configs/default_defconfig | 1 +
>> arch/s390/configs/gcov_defconfig | 1 +
>> arch/s390/configs/performance_defconfig | 1 +
>> arch/s390/defconfig | 1 +
>> drivers/s390/crypto/Makefile | 6 +-
>> drivers/s390/crypto/ap_matrix_bus.c | 8 ++
>> drivers/s390/crypto/ap_matrix_bus.h | 2 +-
>> drivers/s390/crypto/vfio_ap_matrix_drv.c | 102 ++++++++++++++++++++++++++
>> drivers/s390/crypto/vfio_ap_matrix_private.h | 47 ++++++++++++
>> 11 files changed, 182 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/s390/crypto/vfio_ap_matrix_drv.c
>> create mode 100644 drivers/s390/crypto/vfio_ap_matrix_private.h
>>
>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>> index 48af970..411c19a 100644
>> --- a/arch/s390/Kconfig
>> +++ b/arch/s390/Kconfig
>> @@ -722,6 +722,19 @@ config VFIO_CCW
>> To compile this driver as a module, choose M here: the
>> module will be called vfio_ccw.
>>
>> +config VFIO_AP_MATRIX
>> + def_tristate m
>> + prompt "Support for Adjunct Processor Matrix device interface"
>> + depends on ZCRYPT
>> + select VFIO
>> + select MDEV
>> + select VFIO_MDEV
>> + select VFIO_MDEV_DEVICE
>> + select IOMMU_API
> I think the more common pattern is to depend on the VFIO configs
> instead of selecting them.
It's ironic because I originally changed from using 'depends on' and
changed it based on review comments made
on our internal mailing list. I'll go with 'depends on'.
>
>> + help
>> + driver grants access to Adjunct Processor (AP) devices
>> + via the VFIO mediated device interface.
>> +
>> endmenu
>>
>> menu "Dump support"
>> diff --git a/drivers/s390/crypto/Makefile b/drivers/s390/crypto/Makefile
>> index 87646ca..1983afa 100644
>> --- a/drivers/s390/crypto/Makefile
>> +++ b/drivers/s390/crypto/Makefile
>> @@ -13,4 +13,8 @@ obj-$(CONFIG_ZCRYPT) += zcrypt_pcixcc.o zcrypt_cex2a.o zcrypt_cex4.o
>>
>> # pkey kernel module
>> pkey-objs := pkey_api.o
>> -obj-$(CONFIG_PKEY) += pkey.o
>> \ No newline at end of file
>> +obj-$(CONFIG_PKEY) += pkey.o
> Another change of that line.
Will fix this
>
>> +
>> +# adjunct processor matrix
>> +vfio_ap_matrix-objs := vfio_ap_matrix_drv.o
>> +obj-$(CONFIG_VFIO_AP_MATRIX) += vfio_ap_matrix.o
>> diff --git a/drivers/s390/crypto/ap_matrix_bus.c b/drivers/s390/crypto/ap_matrix_bus.c
>> index 4eb1e3c..66bfa54 100644
>> --- a/drivers/s390/crypto/ap_matrix_bus.c
>> +++ b/drivers/s390/crypto/ap_matrix_bus.c
>> @@ -75,10 +75,18 @@ static int ap_matrix_dev_create(void)
>> return 0;
>> }
>>
>> +struct ap_matrix *ap_matrix_get_device(void)
>> +{
>> + return matrix;
> See the comments I had for the previous patch. In particular, I think
> it is better to retrieve a pointer to the matrix device via driver core
> methods.
I got some objections to creating a new bus and since there will only ever
be a single AP matrix device, I decided there really wasn't a need for an
AP matrix bus and got rid of it. I opted instead to create the matrix
device
in the init function of the vfio_ap_matrix driver. Rather than passing
around a
pointer, I put the following in vfio_ap_matrix_private.h:
struct ap_matrix {
struct device device;
spinlock_t qlock;
struct list_head queues;
};
extern struct ap_matrix ap_matrix;
... and declared the ap_matrix in the driver (vfio_ap_matrix_drv.c)
file as:
struct ap_matrix ap_matrix;
Does this seem like a reasonable approach?
>
>> +}
>> +EXPORT_SYMBOL(ap_matrix_get_device);
>> +
>> int __init ap_matrix_init(void)
>> {
>> int ret;
>>
>> + matrix = NULL;
>> +
>> ap_matrix_root_device = root_device_register(AP_MATRIX_BUS_NAME);
>> ret = PTR_RET(ap_matrix_root_device);
>> if (ret)
>> diff --git a/drivers/s390/crypto/ap_matrix_bus.h b/drivers/s390/crypto/ap_matrix_bus.h
>> index 225db4f..c2aff23 100644
>> --- a/drivers/s390/crypto/ap_matrix_bus.h
>> +++ b/drivers/s390/crypto/ap_matrix_bus.h
>> @@ -16,6 +16,6 @@ struct ap_matrix {
>> struct device device;
>> };
>>
>> -int ap_matrix_init(void);
> So, was that not needed before?
Forgot to remove it when I refactored a previous patch in which was
introduced.
>
>> +struct ap_matrix *ap_matrix_get_device(void);
>>
>> #endif /* _AP_MATRIX_BUS_H_ */
>> diff --git a/drivers/s390/crypto/vfio_ap_matrix_drv.c b/drivers/s390/crypto/vfio_ap_matrix_drv.c
>> new file mode 100644
>> index 0000000..760ed56
>> --- /dev/null
>> +++ b/drivers/s390/crypto/vfio_ap_matrix_drv.c
>> @@ -0,0 +1,102 @@
>> +/*
>> + * VFIO based AP Matrix device driver
>> + *
>> + * Copyright IBM Corp. 2017
>> + *
>> + * Author(s): Tony Krowiak <akrowiak@linux.vnet.ibm.com>
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/mod_devicetable.h>
>> +#include <linux/slab.h>
>> +
>> +#include "ap_bus.h"
>> +#include "ap_matrix_bus.h"
>> +#include "vfio_ap_matrix_private.h"
>> +
>> +#define VFIO_AP_MATRIX_DRV_NAME "vfio_ap_queue"
>> +
>> +MODULE_AUTHOR("IBM Corporation");
>> +MODULE_DESCRIPTION("AP Matrix device driver, Copyright IBM Corp. 2017");
>> +MODULE_LICENSE("GPL v2");
>> +
>> +static struct ap_device_id ap_queue_ids[] = {
>> + { .dev_type = AP_DEVICE_TYPE_CEX4,
>> + .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE },
>> + { .dev_type = AP_DEVICE_TYPE_CEX5,
>> + .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE },
>> + { .dev_type = AP_DEVICE_TYPE_CEX6,
>> + .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE },
> So, you explicitly don't match to all devices, but only to the newer
> ones? This needs an explaining comment.
Okay
>
>> + { /* end of list */ },
>> +};
>> +
>> +MODULE_DEVICE_TABLE(ap_matrix, ap_queue_ids);
>> +
>> +static struct ap_matrix_driver {
>> + struct ap_driver ap_drv;
>> + struct ap_matrix *ap_matrix;
> Do you actually need that pointer to the matrix device? One usage is to
> pass it as an parameter to the mdev registration in the next patch. As
> you only support one matrix device, would it be better to move getting
> that device into the mdev code?
>
> For the other usage, move getting it into find_vapq()?
See my comments above regarding getting rid of the AP matrix bus.
>
>> +} vfio_ap_matrix_drv;
>> +
>> +static int ap_matrix_queue_dev_probe(struct ap_device *apdev)
>> +{
>> + struct vfio_ap_queue *vapq;
>> + struct ap_queue *apq = to_ap_queue(&apdev->device);
>> + struct ap_matrix *ap_matrix = vfio_ap_matrix_drv.ap_matrix;
>> +
>> + vapq = kzalloc(sizeof(*vapq), GFP_KERNEL);
>> + if (!vapq)
>> + return -ENOMEM;
>> +
>> + INIT_LIST_HEAD(&vapq->list);
>> + vapq->queue = apq;
>> + spin_lock_bh(&ap_matrix->qlock);
>> + list_add_tail(&vapq->list, &ap_matrix->queues);
>> + spin_unlock_bh(&ap_matrix->qlock);
>> +
>> + return 0;
>> +}
>> +
>> +static void ap_matrix_queue_dev_remove(struct ap_device *apdev)
>> +{
>> + struct vfio_ap_queue *vapq;
>> + struct ap_queue *apq = to_ap_queue(&apdev->device);
>> + struct ap_matrix *ap_matrix = vfio_ap_matrix_drv.ap_matrix;
>> +
>> + vapq = find_vapq(ap_matrix, apq->qid);
>> +
>> + if (vapq) {
>> + spin_lock_bh(&ap_matrix->qlock);
>> + list_del_init(&vapq->list);
>> + spin_unlock_bh(&ap_matrix->qlock);
>> + kfree(vapq);
>> + }
>> +}
>> +
>> +int __init ap_matrix_init(void)
>> +{
>> +
>> + int ret;
>> +
>> + vfio_ap_matrix_drv.ap_matrix = ap_matrix_get_device();
>> + if (!vfio_ap_matrix_drv.ap_matrix)
>> + return -ENODEV;
>> +
>> + vfio_ap_matrix_drv.ap_drv.probe = ap_matrix_queue_dev_probe;
>> + vfio_ap_matrix_drv.ap_drv.remove = ap_matrix_queue_dev_remove;
>> + vfio_ap_matrix_drv.ap_drv.ids = ap_queue_ids;
> Can you use an static initializer for that?
This is how its done for the AP bus drivers, for example; see zcrypt_cex4.c.
>
>> +
>> + ret = ap_driver_register(&vfio_ap_matrix_drv.ap_drv,
>> + THIS_MODULE, VFIO_AP_MATRIX_DRV_NAME);
>> + if (ret)
>> + return ret;
>> +
>> + return ret;
>> +}
>> +
>> +void __exit ap_matrix_exit(void)
>> +{
>> + ap_driver_unregister(&vfio_ap_matrix_drv.ap_drv);
>> +}
>> +
>> +module_init(ap_matrix_init);
>> +module_exit(ap_matrix_exit);
>> diff --git a/drivers/s390/crypto/vfio_ap_matrix_private.h b/drivers/s390/crypto/vfio_ap_matrix_private.h
>> new file mode 100644
>> index 0000000..11c5e02
>> --- /dev/null
>> +++ b/drivers/s390/crypto/vfio_ap_matrix_private.h
>> @@ -0,0 +1,47 @@
>> +/*
>> + * Private data and functions for adjunct processor VFIO matrix driver.
>> + *
>> + * Copyright IBM Corp. 2016
>> + * Author(s): Tony Krowiak <akrowiak@linux.vnet.ibm.com>
>> + */
>> +
>> +#ifndef _VFIO_AP_PRIVATE_H_
>> +#define _VFIO_AP_PRIVATE_H_
>> +
>> +#include <linux/types.h>
>> +
>> +#include "ap_bus.h"
>> +#include "ap_matrix_bus.h"
>> +
>> +#define VFIO_AP_MATRIX_MODULE_NAME "vfio_ap_matrix"
>> +
>> +struct vfio_ap_queue {
>> + struct ap_queue *queue;
>> + struct list_head list;
>> +};
>> +
>> +static inline struct vfio_ap_queue *to_vapq(struct ap_device *ap_dev)
>> +{
>> + struct ap_queue *ap_queue = to_ap_queue(&ap_dev->device);
>> + struct vfio_ap_queue *vapq;
>> +
>> + vapq = container_of(&ap_queue, struct vfio_ap_queue, queue);
> Why not just return container_of(...); ?
Will change it.
>
>> +
>> + return vapq;
>> +}
>> +
>> +static inline struct vfio_ap_queue *find_vapq(struct ap_matrix *ap_matrix,
>> + ap_qid_t qid)
>> +{
>> + struct vfio_ap_queue *vapq;
>> +
>> + if (!list_empty(&ap_matrix->queues)) {
>> + list_for_each_entry(vapq, &ap_matrix->queues, list)
>> + if (vapq->queue->qid == qid)
>> + return vapq;
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +#endif /* _VFIO_AP_PRIVATE_H_ */
next prev parent reply other threads:[~2017-11-14 16:37 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-13 17:38 [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters Tony Krowiak
2017-10-13 17:38 ` [RFC 01/19] KVM: s390: SIE considerations for AP Queue virtualization Tony Krowiak
2017-11-02 11:54 ` Christian Borntraeger
2017-11-02 19:53 ` Tony Krowiak
2017-10-13 17:38 ` [RFC 02/19] KVM: s390: refactor crypto initialization Tony Krowiak
2017-11-02 12:41 ` Christian Borntraeger
2017-11-14 11:50 ` Cornelia Huck
2017-11-14 15:53 ` Tony Krowiak
2017-10-13 17:38 ` [RFC 03/19] s390/zcrypt: new AP matrix bus Tony Krowiak
2017-10-16 8:47 ` Martin Schwidefsky
2017-10-16 15:02 ` Tony Krowiak
2017-11-14 11:58 ` Cornelia Huck
2017-11-14 13:19 ` Tony Krowiak
2017-11-14 15:54 ` Tony Krowiak
2017-11-14 16:07 ` Tony Krowiak
2017-10-13 17:38 ` [RFC 04/19] s390/zcrypt: create an AP matrix device on the " Tony Krowiak
2017-10-18 16:20 ` Cornelia Huck
2017-10-18 17:54 ` Tony Krowiak
2017-10-13 17:38 ` [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver Tony Krowiak
2017-10-16 8:59 ` Martin Schwidefsky
2017-10-16 15:56 ` Tony Krowiak
2017-11-14 12:40 ` Cornelia Huck
2017-11-14 16:37 ` Tony Krowiak [this message]
2017-11-14 17:00 ` Cornelia Huck
2017-11-14 18:15 ` Tony Krowiak
2017-11-15 10:31 ` Cornelia Huck
2017-11-16 12:02 ` Pierre Morel
2017-11-16 12:35 ` Cornelia Huck
2017-11-16 14:25 ` Tony Krowiak
2017-11-16 16:47 ` Cornelia Huck
2017-11-17 21:13 ` Tony Krowiak
2017-11-20 17:15 ` Cornelia Huck
2017-11-16 14:25 ` Pierre Morel
2017-10-13 17:38 ` [RFC 06/19] s390/zcrypt: register matrix device with VFIO mediated device framework Tony Krowiak
2017-10-16 9:03 ` Martin Schwidefsky
2017-10-16 16:09 ` Tony Krowiak
2017-11-14 13:14 ` Cornelia Huck
2017-11-16 15:37 ` Tony Krowiak
2017-10-13 17:38 ` [RFC 07/19] KVM: s390: introduce AP matrix configuration interface Tony Krowiak
2017-10-16 9:10 ` Martin Schwidefsky
2017-10-16 16:26 ` Tony Krowiak
2017-11-14 13:16 ` Cornelia Huck
2017-11-16 15:41 ` Tony Krowiak
2017-10-13 17:38 ` [RFC 08/19] s390/zcrypt: support for assigning adapters to matrix mdev Tony Krowiak
2017-11-14 13:22 ` Cornelia Huck
2017-11-16 23:53 ` Tony Krowiak
2017-11-17 9:50 ` Cornelia Huck
2017-10-13 17:38 ` [RFC 09/19] s390/zcrypt: validate adapter assignment Tony Krowiak
2017-10-13 17:38 ` [RFC 10/19] s390/zcrypt: sysfs interfaces supporting AP domain assignment Tony Krowiak
2017-10-13 17:38 ` [RFC 11/19] s390/zcrypt: validate " Tony Krowiak
2017-10-13 17:38 ` [RFC 12/19] s390/zcrypt: sysfs support for control " Tony Krowiak
2017-10-13 17:38 ` [RFC 13/19] s390/zcrypt: validate " Tony Krowiak
2017-10-16 9:13 ` Martin Schwidefsky
2017-10-13 17:38 ` [RFC 14/19] KVM: s390: Connect the AP mediated matrix device to KVM Tony Krowiak
2017-10-13 17:39 ` [RFC 15/19] s390/zcrypt: introduce ioctl access to VFIO AP Matrix driver Tony Krowiak
2017-10-13 17:39 ` [RFC 16/19] KVM: s390: interface to configure KVM guest's AP matrix Tony Krowiak
2017-10-16 20:22 ` Tony Krowiak
2017-11-14 13:46 ` Cornelia Huck
2017-10-13 17:39 ` [RFC 17/19] KVM: s390: validate input to AP matrix config interface Tony Krowiak
2017-10-13 17:39 ` [RFC 18/19] KVM: s390: New ioctl to configure KVM guest's AP matrix Tony Krowiak
2017-11-02 18:55 ` Tony Krowiak
2017-10-13 17:39 ` [RFC 19/19] s390/facilities: enable AP facilities needed by guest Tony Krowiak
2017-10-16 9:25 ` Martin Schwidefsky
2017-11-02 12:08 ` Christian Borntraeger
2017-11-02 12:23 ` Halil Pasic
[not found] ` <af1bb867-f9a0-458b-b7b2-c0bb9456eb7f@linux.vnet.ibm.com>
2017-11-02 15:53 ` Christian Borntraeger
2017-11-02 18:49 ` Tony Krowiak
2017-11-03 8:47 ` Christian Borntraeger
2017-12-02 1:30 ` Tony Krowiak
2017-12-05 7:52 ` Harald Freudenberger
2017-12-05 14:04 ` Cornelia Huck
2017-12-05 14:23 ` Pierre Morel
2017-12-05 14:30 ` Cornelia Huck
2017-12-05 14:47 ` Pierre Morel
2017-12-05 15:14 ` Tony Krowiak
2017-12-05 15:01 ` Tony Krowiak
2017-12-06 9:15 ` Pierre Morel
2017-12-06 10:15 ` Cornelia Huck
2017-12-05 14:14 ` Tony Krowiak
[not found] ` <OF182217F7.6A47A64E-ON002581CD.002BCF58-C12581CD.002D4127@notes.na.collabserv.com>
2017-11-03 8:49 ` Christian Borntraeger
2017-10-16 9:27 ` [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters Martin Schwidefsky
2017-10-16 10:06 ` Christian Borntraeger
2017-10-16 16:30 ` Tony Krowiak
2017-10-16 10:05 ` Cornelia Huck
2017-10-16 16:27 ` Tony Krowiak
2017-10-18 16:43 ` Christian Borntraeger
2017-10-29 11:11 ` Cornelia Huck
2017-10-30 8:57 ` Christian Borntraeger
2017-10-30 19:04 ` Tony Krowiak
2017-10-31 19:39 ` Tony Krowiak
2017-11-14 13:57 ` Cornelia Huck
2017-11-16 15:23 ` Tony Krowiak
2017-11-16 16:06 ` Pierre Morel
2017-11-16 17:03 ` Cornelia Huck
2017-11-16 20:25 ` Pierre Morel
2017-11-16 23:35 ` Tony Krowiak
2017-11-17 7:07 ` Pierre Morel
2017-11-17 10:07 ` Cornelia Huck
2017-11-17 20:28 ` Tony Krowiak
2017-11-20 17:13 ` Cornelia Huck
2017-11-21 16:08 ` Tony Krowiak
2017-11-22 13:47 ` Cornelia Huck
2017-11-28 0:39 ` Tony Krowiak
2017-12-05 14:06 ` Cornelia Huck
2017-12-05 15:09 ` Tony Krowiak
2017-11-16 16:49 ` Cornelia Huck
2017-11-16 23:41 ` Tony Krowiak
2017-11-17 9:49 ` Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=06ddee4e-e1b8-ba17-5e3e-241e4dcf7cd0@linux.vnet.ibm.com \
--to=akrowiak@linux.vnet.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=alifm@linux.vnet.ibm.com \
--cc=bjsdjshi@linux.vnet.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=freude@de.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=jjherne@linux.vnet.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.vnet.ibm.com \
--cc=pasic@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=pmorel@linux.vnet.ibm.com \
--cc=qemu-s390x@nongnu.org \
--cc=schwidefsky@de.ibm.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).