From: Julien Grall <julien.grall@arm.com>
To: Andre Przywara <andre.przywara@linaro.org>,
Stefano Stabellini <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [RFC PATCH 24/49] ARM: new VGIC: Add IRQ sync/flush framework
Date: Tue, 13 Feb 2018 12:41:06 +0000 [thread overview]
Message-ID: <0a43b818-ed1c-baac-7304-e46573a368b7@arm.com> (raw)
In-Reply-To: <20180209143937.28866-25-andre.przywara@linaro.org>
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
> Implement the framework for syncing IRQs between our emulation and the
> list registers, which represent the guest's view of IRQs.
> This is done in kvm_vgic_flush_hwstate and kvm_vgic_sync_hwstate, which
You probably want to update the names here.
> gets called on guest entry and exit.
> The code talking to the actual GICv2/v3 hardware is added in the
> following patches.
>
> This is based on Linux commit 0919e84c0fc1, written by Marc Zyngier.
>
> Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
> ---
> xen/arch/arm/vgic/vgic.c | 246 +++++++++++++++++++++++++++++++++++++++++++++++
> xen/arch/arm/vgic/vgic.h | 2 +
> 2 files changed, 248 insertions(+)
>
> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
> index a4efd1fd03..a1f77130d4 100644
> --- a/xen/arch/arm/vgic/vgic.c
> +++ b/xen/arch/arm/vgic/vgic.c
> @@ -380,6 +380,252 @@ int vgic_inject_irq(struct domain *d, struct vcpu *vcpu, unsigned int intid,
> return 0;
> }
>
> +/**
> + * vgic_prune_ap_list - Remove non-relevant interrupts from the list
> + *
> + * @vcpu: The VCPU pointer
> + *
> + * Go over the list of "interesting" interrupts, and prune those that we
> + * won't have to consider in the near future.
> + */
> +static void vgic_prune_ap_list(struct vcpu *vcpu)
> +{
> + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> + struct vgic_irq *irq, *tmp;
> + unsigned long flags;
> +
> +retry:
> + spin_lock_irqsave(&vgic_cpu->ap_list_lock, flags);
> +
> + list_for_each_entry_safe( irq, tmp, &vgic_cpu->ap_list_head, ap_list )
See my comment on patch #22, this is where I am worry about going
through the list every time we enter to the hypervisor from the guest.
> + {
> + struct vcpu *target_vcpu, *vcpuA, *vcpuB;
> +
> + spin_lock(&irq->irq_lock);
> +
> + BUG_ON(vcpu != irq->vcpu);
> +
> + target_vcpu = vgic_target_oracle(irq);
> +
> + if ( !target_vcpu )
> + {
> + /*
> + * We don't need to process this interrupt any
> + * further, move it off the list.
> + */
> + list_del(&irq->ap_list);
> + irq->vcpu = NULL;
> + spin_unlock(&irq->irq_lock);
> +
> + /*
> + * This vgic_put_irq call matches the
> + * vgic_get_irq_kref in vgic_queue_irq_unlock,
> + * where we added the LPI to the ap_list. As
> + * we remove the irq from the list, we drop
> + * also drop the refcount.
> + */
> + vgic_put_irq(vcpu->domain, irq);
> + continue;
> + }
> +
> + if ( target_vcpu == vcpu )
> + {
> + /* We're on the right CPU */
> + spin_unlock(&irq->irq_lock);
> + continue;
> + }
> +
> + /* This interrupt looks like it has to be migrated. */
> +
> + spin_unlock(&irq->irq_lock);
> + spin_unlock_irqrestore(&vgic_cpu->ap_list_lock, flags);
> +
> + /*
> + * Ensure locking order by always locking the smallest
> + * ID first.
> + */
> + if ( vcpu->vcpu_id < target_vcpu->vcpu_id )
> + {
> + vcpuA = vcpu;
> + vcpuB = target_vcpu;
> + }
> + else
> + {
> + vcpuA = target_vcpu;
> + vcpuB = vcpu;
> + }
> +
> + spin_lock_irqsave(&vcpuA->arch.vgic_cpu.ap_list_lock, flags);
> + spin_lock(&vcpuB->arch.vgic_cpu.ap_list_lock);
> + spin_lock(&irq->irq_lock);
> +
> + /*
> + * If the affinity has been preserved, move the
> + * interrupt around. Otherwise, it means things have
> + * changed while the interrupt was unlocked, and we
> + * need to replay this.
> + *
> + * In all cases, we cannot trust the list not to have
> + * changed, so we restart from the beginning.
> + */
> + if ( target_vcpu == vgic_target_oracle(irq) )
> + {
> + struct vgic_cpu *new_cpu = &target_vcpu->arch.vgic_cpu;
> +
> + list_del(&irq->ap_list);
> + irq->vcpu = target_vcpu;
> + list_add_tail(&irq->ap_list, &new_cpu->ap_list_head);
> + }
> +
> + spin_unlock(&irq->irq_lock);
> + spin_unlock(&vcpuB->arch.vgic_cpu.ap_list_lock);
> + spin_unlock_irqrestore(&vcpuA->arch.vgic_cpu.ap_list_lock, flags);
> + goto retry;
> + }
> +
> + spin_unlock_irqrestore(&vgic_cpu->ap_list_lock, flags);
> +}
> +
> +static inline void vgic_fold_lr_state(struct vcpu *vcpu)
> +{
> +}
> +
> +/* Requires the irq_lock to be held. */
> +static inline void vgic_populate_lr(struct vcpu *vcpu,
> + struct vgic_irq *irq, int lr)
> +{
> + ASSERT(spin_is_locked(&irq->irq_lock));
> +}
> +
> +static inline void vgic_clear_lr(struct vcpu *vcpu, int lr)
> +{
> +}
> +
> +static inline void vgic_set_underflow(struct vcpu *vcpu)
> +{
> +}
> +
> +/* Requires the ap_list_lock to be held. */
> +static int compute_ap_list_depth(struct vcpu *vcpu)
> +{
> + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> + struct vgic_irq *irq;
> + int count = 0;
> +
> + ASSERT(spin_is_locked(&vgic_cpu->ap_list_lock));
> +
> + list_for_each_entry(irq, &vgic_cpu->ap_list_head, ap_list)
Here another example.
> + {
> + spin_lock(&irq->irq_lock);
> + /* GICv2 SGIs can count for more than one... */
> + if ( vgic_irq_is_sgi(irq->intid) && irq->source )
> + count += hweight8(irq->source);
> + else
> + count++;
> + spin_unlock(&irq->irq_lock);
> + }
> + return count;
> +}
> +
> +/* Requires the VCPU's ap_list_lock to be held. */
> +static void vgic_flush_lr_state(struct vcpu *vcpu)
> +{
> + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> + struct vgic_irq *irq;
> + int count = 0;
> +
> + ASSERT(spin_is_locked(&vgic_cpu->ap_list_lock));
> +
> + if ( compute_ap_list_depth(vcpu) > gic_get_nr_lrs() )
> + vgic_sort_ap_list(vcpu);
> +
> + list_for_each_entry( irq, &vgic_cpu->ap_list_head, ap_list )
> + {
> + spin_lock(&irq->irq_lock);
> +
> + if ( unlikely(vgic_target_oracle(irq) != vcpu) )
> + goto next;
> +
> + /*
> + * If we get an SGI with multiple sources, try to get
> + * them in all at once.
> + */
> + do
> + {
> + vgic_populate_lr(vcpu, irq, count++);
> + } while ( irq->source && count < gic_get_nr_lrs() );
> +
> +next:
> + spin_unlock(&irq->irq_lock);
> +
> + if ( count == gic_get_nr_lrs() )
> + {
> + if ( !list_is_last(&irq->ap_list, &vgic_cpu->ap_list_head) )
> + vgic_set_underflow(vcpu);
> + break;
> + }
> + }
> +
> + vcpu->arch.vgic_cpu.used_lrs = count;
> +
> + /* Nuke remaining LRs */
> + for ( ; count < gic_get_nr_lrs(); count++)
> + vgic_clear_lr(vcpu, count);
> +}
> +
> +/*
> + * gic_clear_lrs() - Update the VGIC state from hardware after a guest's run.
> + * @vcpu: the VCPU.
> + *
> + * Sync back the hardware VGIC state after the guest has run, into our
> + * VGIC emulation structures, It reads the LRs and updates the respective
> + * struct vgic_irq, taking level/edge into account.
> + * This is the high level function which takes care of the conditions,
> + * also bails out early if there were no interrupts queued.
> + * Was: kvm_vgic_sync_hwstate()
> + */
> +void gic_clear_lrs(struct vcpu *vcpu)
I think I would prefer if we stick with the KVM name.
> +{
> + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> +
> + /* An empty ap_list_head implies used_lrs == 0 */
> + if ( list_empty(&vcpu->arch.vgic_cpu.ap_list_head) )
> + return;
> +
> + if ( vgic_cpu->used_lrs )
> + vgic_fold_lr_state(vcpu);
> + vgic_prune_ap_list(vcpu);
> +}
> +
> +/*
> + * gic_inject() - flush the emulation state into the hardware on guest entry
> + *
> + * Before we enter a guest, we have to translate the virtual GIC state of a
> + * VCPU into the GIC virtualization hardware registers, namely the LRs.
> + * This is the high level function which takes care about the conditions
> + * and the locking, also bails out early if there are no interrupts queued.
> + * Was: kvm_vgic_flush_hwstate()
Ditto.
> + */
> +void gic_inject(void)
> +{
> + /*
> + * If there are no virtual interrupts active or pending for this
> + * VCPU, then there is no work to do and we can bail out without
> + * taking any lock. There is a potential race with someone injecting
> + * interrupts to the VCPU, but it is a benign race as the VCPU will
> + * either observe the new interrupt before or after doing this check,
> + * and introducing additional synchronization mechanism doesn't change
> + * this.
> + */
> + if ( list_empty(¤t->arch.vgic_cpu.ap_list_head) )
> + return;
> +
> + ASSERT(!local_irq_is_enabled());
> +
> + spin_lock(¤t->arch.vgic_cpu.ap_list_lock);
> + vgic_flush_lr_state(current);
> + spin_unlock(¤t->arch.vgic_cpu.ap_list_lock);
> +}
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
> index 5127739f0f..47fc58b81e 100644
> --- a/xen/arch/arm/vgic/vgic.h
> +++ b/xen/arch/arm/vgic/vgic.h
> @@ -17,6 +17,8 @@
> #ifndef __XEN_ARM_VGIC_NEW_H__
> #define __XEN_ARM_VGIC_NEW_H__
>
> +#define vgic_irq_is_sgi(intid) ((intid) < VGIC_NR_SGIS)
> +
> static inline bool irq_is_pending(struct vgic_irq *irq)
> {
> if ( irq->config == VGIC_CONFIG_EDGE )
>
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-02-13 12:41 UTC|newest]
Thread overview: 154+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-09 14:38 [RFC PATCH 00/49] New VGIC(-v2) implementation Andre Przywara
2018-02-09 14:38 ` [RFC PATCH 01/49] tools: ARM: vGICv3: avoid inserting optional DT properties Andre Przywara
2018-02-09 19:14 ` Julien Grall
2018-02-09 14:38 ` [RFC PATCH 02/49] ARM: vGICv3: drop GUEST_GICV3_RDIST_REGIONS symbol Andre Przywara
2018-02-09 14:38 ` [RFC PATCH 03/49] ARM: GICv3: use hardware GICv3 redistributor regions for Dom0 Andre Przywara
2018-02-09 14:38 ` [RFC PATCH 04/49] ARM: GICv3: simplify GICv3 redistributor stride handling Andre Przywara
2018-02-09 14:38 ` [RFC PATCH 05/49] ARM: vGICv3: always use architected redist stride Andre Przywara
2018-02-09 14:38 ` [RFC PATCH 06/49] ARM: vGICv3: remove rdist_stride from VGIC structure Andre Przywara
2018-02-09 14:38 ` [RFC PATCH 07/49] ARM: VGIC: move gic_remove_from_lr_pending() prototype Andre Przywara
2018-02-09 19:15 ` Julien Grall
2018-02-09 14:38 ` [RFC PATCH 08/49] ARM: VGIC: move max_vcpus VGIC limit to struct arch_domain Andre Przywara
2018-02-09 19:27 ` Julien Grall
2018-02-28 12:32 ` Andre Przywara
2018-02-28 13:04 ` Julien Grall
2018-02-09 14:38 ` [RFC PATCH 09/49] ARM: VGIC: change to level-IRQ compatible IRQ injection interface Andre Przywara
2018-02-12 11:15 ` Julien Grall
2018-02-12 11:59 ` Andre Przywara
2018-02-12 12:19 ` Julien Grall
2018-02-12 14:24 ` Andre Przywara
2018-02-13 11:49 ` Julien Grall
2018-02-09 14:38 ` [RFC PATCH 10/49] ARM: VGIC: carve out struct vgic_cpu and struct vgic_dist Andre Przywara
2018-02-12 11:19 ` Julien Grall
2018-02-09 14:38 ` [RFC PATCH 11/49] ARM: VGIC: reorder prototypes in vgic.h Andre Przywara
2018-02-12 11:53 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 12/49] ARM: VGIC: introduce gic_get_nr_lrs() Andre Przywara
2018-02-12 11:57 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 13/49] ARM: VGIC: Add hypervisor base address to vgic_v2_setup_hw() Andre Przywara
2018-02-12 12:07 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 14/49] ARM: VGIC: extend GIC CPU interface definitions Andre Przywara
2018-02-12 12:34 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 15/49] ARM: GIC: Allow tweaking the active state of an IRQ Andre Przywara
2018-02-12 13:55 ` Julien Grall
2018-02-12 17:53 ` Andre Przywara
2018-02-13 12:02 ` Julien Grall
2018-02-13 15:01 ` Andre Przywara
2018-02-16 15:07 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 16/49] ARM: GIC: allow reading pending state of a hardware IRQ Andre Przywara
2018-02-12 14:00 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 17/49] ARM: timer: Handle level triggered IRQs correctly Andre Przywara
2018-02-12 15:19 ` Julien Grall
2018-02-12 18:23 ` Andre Przywara
2018-02-13 12:05 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 18/49] ARM: evtchn: " Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 19/49] ARM: vPL011: Use the VGIC's level triggered IRQs handling if available Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 20/49] ARM: new VGIC: Add data structure definitions Andre Przywara
2018-02-12 16:42 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 21/49] ARM: new VGIC: Add acccessor to new struct vgic_irq instance Andre Przywara
2018-02-12 17:42 ` Julien Grall
2018-02-13 11:18 ` Andre Przywara
2018-02-16 15:16 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 22/49] ARM: new VGIC: Implement virtual IRQ injection Andre Przywara
2018-02-12 18:59 ` Julien Grall
2018-02-27 10:17 ` Andre Przywara
2018-02-27 10:43 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 23/49] ARM: new VGIC: Add IRQ sorting Andre Przywara
2018-02-13 12:30 ` Julien Grall
2018-02-13 14:56 ` Andre Przywara
2018-02-13 15:00 ` Julien Grall
2018-02-13 16:21 ` Christoffer Dall
2018-02-09 14:39 ` [RFC PATCH 24/49] ARM: new VGIC: Add IRQ sync/flush framework Andre Przywara
2018-02-13 12:41 ` Julien Grall [this message]
2018-02-13 15:40 ` Andre Przywara
2018-02-16 15:22 ` Julien Grall
2018-02-13 14:31 ` Julien Grall
2018-02-13 14:56 ` Andre Przywara
2018-02-13 15:01 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 25/49] ARM: new VGIC: Add GICv2 world switch backend Andre Przywara
2018-02-13 14:31 ` Julien Grall
2018-02-26 15:13 ` Andre Przywara
2018-02-26 16:02 ` Julien Grall
2018-02-26 16:19 ` Andre Przywara
2018-02-26 15:16 ` Andre Przywara
2018-02-26 15:59 ` Julien Grall
2018-02-26 16:23 ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 26/49] ARM: new VGIC: Implement vgic_vcpu_pending_irq Andre Przywara
2018-02-13 16:35 ` Julien Grall
2018-02-13 16:36 ` Julien Grall
2018-02-26 15:29 ` Andre Przywara
2018-02-26 15:55 ` Julien Grall
2018-02-26 16:25 ` Andre Przywara
2018-02-26 16:30 ` Julien Grall
2018-03-02 13:53 ` Andre Przywara
2018-03-02 13:58 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 27/49] ARM: new VGIC: Add MMIO handling framework Andre Przywara
2018-02-13 16:52 ` Julien Grall
2018-02-13 18:17 ` Andre Przywara
2018-02-16 15:25 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 28/49] ARM: new VGIC: Add GICv2 " Andre Przywara
2018-02-16 15:39 ` Julien Grall
2018-02-19 12:23 ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 29/49] ARM: new VGIC: Add CTLR, TYPER and IIDR handlers Andre Przywara
2018-02-16 15:56 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 30/49] ARM: new VGIC: Add ENABLE registers handlers Andre Przywara
2018-02-16 16:57 ` Julien Grall
2018-02-19 12:41 ` Andre Przywara
2018-02-19 14:13 ` Julien Grall
2018-02-27 13:54 ` Andre Przywara
2018-02-27 14:34 ` Julien Grall
2018-02-23 15:18 ` Andre Przywara
2018-02-26 11:20 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 31/49] ARM: new VGIC: Add PENDING " Andre Przywara
2018-02-16 17:16 ` Julien Grall
2018-02-19 15:32 ` Andre Przywara
2018-02-19 15:43 ` Julien Grall
2018-03-02 16:36 ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 32/49] ARM: new VGIC: Add ACTIVE " Andre Przywara
2018-02-16 17:30 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 33/49] ARM: new VGIC: Add PRIORITY " Andre Przywara
2018-02-16 17:38 ` Julien Grall
2018-02-23 14:47 ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 34/49] ARM: new VGIC: Add CONFIG " Andre Przywara
2018-02-19 11:39 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 35/49] ARM: new VGIC: Add TARGET " Andre Przywara
2018-02-19 11:53 ` Julien Grall
2018-02-23 11:25 ` Andre Przywara
2018-02-19 12:30 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 36/49] ARM: new VGIC: Add SGIR register handler Andre Przywara
2018-02-19 11:59 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 37/49] ARM: new VGIC: Add SGIPENDR register handlers Andre Przywara
2018-02-19 12:02 ` Julien Grall
2018-02-23 11:39 ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 38/49] ARM: new VGIC: handle hardware mapped IRQs Andre Przywara
2018-02-19 12:19 ` Julien Grall
2018-02-23 18:02 ` Andre Przywara
2018-02-23 18:14 ` Julien Grall
2018-02-26 16:48 ` Andre Przywara
2018-02-26 16:57 ` Julien Grall
2018-02-26 17:19 ` Andre Przywara
2018-02-26 17:26 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 39/49] ARM: new VGIC: Add event channel IRQ handling Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 40/49] ARM: new VGIC: Handle virtual IRQ allocation/reservation Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 41/49] ARM: new VGIC: dump virtual IRQ info Andre Przywara
2018-02-19 12:26 ` Julien Grall
2018-02-26 16:58 ` Andre Przywara
2018-02-26 17:01 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 42/49] ARM: new VGIC: provide system register emulation stub Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 43/49] ARM: new VGIC: Add preliminary stub implementations Andre Przywara
2018-02-19 12:34 ` Julien Grall
2018-02-27 17:05 ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 44/49] ARM: new VGIC: vgic-init: register VGIC Andre Przywara
2018-02-19 12:39 ` Julien Grall
2018-02-26 17:33 ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 45/49] ARM: new VGIC: vgic-init: implement vgic_init Andre Przywara
2018-02-19 13:21 ` Julien Grall
2018-02-19 15:53 ` Andre Przywara
2018-02-19 15:58 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 46/49] ARM: new VGIC: vgic-init: implement map_resources Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 47/49] ARM: new VGIC: Add vgic_v2_enable Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 48/49] ARM: allocate two pages for struct vcpu Andre Przywara
2018-02-19 14:07 ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 49/49] ARM: VGIC: wire new VGIC(-v2) files into Xen build system Andre Przywara
2018-02-09 15:06 ` [RFC PATCH 00/49] New VGIC(-v2) implementation Andre Przywara
2018-02-12 11:48 ` Julien Grall
2018-02-12 11:53 ` Andre Przywara
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=0a43b818-ed1c-baac-7304-e46573a368b7@arm.com \
--to=julien.grall@arm.com \
--cc=andre.przywara@linaro.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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).