On Tue, 20 Oct 2020 09:18:48 +0300
"Kirill A. Shutemov" wrote:
> VirtIO for KVM is a primary way to provide IO. All memory that used for
> communication with the host has to be marked as shared.
>
> The easiest way to archive that is to use DMA API that already knows how
> to deal with shared
On Tue, 20 Oct 2020 09:18:57 +0300
"Kirill A. Shutemov" wrote:
> We cannot access protected pages directly. Use ioremap() to
> create a temporary mapping of the page. The mapping is destroyed
> on __kvm_unmap_gfn().
>
> The new interface gfn_to_pfn_memslot_protected() is used to detect if
> the
On Mon, 5 Oct 2020 12:24:39 -0400
Tony Krowiak wrote:
>
>
> On 9/27/20 9:01 PM, Halil Pasic wrote:
> > On Fri, 21 Aug 2020 15:56:11 -0400
> > Tony Krowiak wrote:
> >
> >> Let's hot plug/unplug adapters, domains and control domains assigned to or
> >
On Wed, 30 Sep 2020 08:59:36 -0400
Tony Krowiak wrote:
> >> @@ -572,6 +455,11 @@ static int vfio_ap_mdev_verify_no_sharing(struct
> >> ap_matrix_mdev *matrix_mdev,
> >>DECLARE_BITMAP(aqm, AP_DOMAINS);
> >>
> >>list_for_each_entry(lstdev, _dev->mdev_list, node) {
> >> + /*
>
On Tue, 29 Sep 2020 12:04:25 -0400
Tony Krowiak wrote:
> >
> > I suppose this is probably about no guest unolies no resources passed
> > through at the moment. If that is the case maybe we can document it
> > below.
>
> I'm not quite sure what you are saying here or what I should be
>
On Tue, 29 Sep 2020 09:07:40 -0400
Tony Krowiak wrote:
>
>
> On 9/24/20 10:27 PM, Halil Pasic wrote:
> > On Fri, 21 Aug 2020 15:56:02 -0400
> > Tony Krowiak wrote:
> >
> >> --- a/drivers/s390/crypto/vfio_ap_ops.c
> >> +++ b/drivers/s3
On Fri, 21 Aug 2020 15:56:16 -0400
Tony Krowiak wrote:
> Update the documentation in vfio-ap.rst to include information about the
> AP dynamic configuration support (i.e., hot plug of adapters, domains
> and control domains via the matrix mediated device's sysfs assignment
> attributes).
If you
On Fri, 21 Aug 2020 15:56:15 -0400
Tony Krowiak wrote:
> AP queue devices are probed or removed for reasons other than changes
> to the host AP configuration. For example:
>
> * The state of an AP adapter can be dynamically changed from standby to
> online via the SE or by execution of the
On Fri, 21 Aug 2020 15:56:14 -0400
Tony Krowiak wrote:
> Implements the driver callback invoked by the AP bus when the AP bus
> scan has completed. Since this callback is invoked after binding the newly
> added devices to their respective device drivers, the vfio_ap driver will
> attempt to plug
On Fri, 21 Aug 2020 15:56:13 -0400
Tony Krowiak wrote:
> Implements the driver callback invoked by the AP bus when the host
> AP configuration has changed. Since this callback is invoked prior to
> unbinding a device from its device driver, the vfio_ap driver will
> respond by unplugging the AP
On Fri, 21 Aug 2020 15:56:11 -0400
Tony Krowiak wrote:
> Let's hot plug/unplug adapters, domains and control domains assigned to or
> unassigned from an AP matrix mdev device while it is in use by a guest per
> the following:
>
> * When the APID of an adapter is assigned to a matrix mdev in use
On Fri, 21 Aug 2020 15:56:12 -0400
Tony Krowiak wrote:
> This patch intruduces an extension to the ap bus to notify drivers
> on crypto config changed and bus scan complete events.
> Two new callbacks are introduced for ap_drivers:
>
> void (*on_config_changed)(struct ap_config_info
On Fri, 21 Aug 2020 15:56:10 -0400
Tony Krowiak wrote:
> The current support for pass-through crypto adapters does not allow
> configuration of a matrix mdev when it is in use by a KVM guest. Let's
> allow AP resources - i.e., adapters, domains and control domains - to be
> assigned to or
On Fri, 21 Aug 2020 15:56:09 -0400
Tony Krowiak wrote:
> The current implementation does not allow assignment of an AP adapter or
> domain to an mdev device if the APQNs resulting from the assignment
> do not reference AP queue devices that are bound to the vfio_ap device
> driver. This patch
On Fri, 21 Aug 2020 15:56:08 -0400
Tony Krowiak wrote:
> Even though APQNs for queues that are not in the host's AP configuration
> may be assigned to a matrix mdev, we do not want to set bits in the guest's
> APCB for APQNs that do not reference AP queue devices bound to the vfio_ap
> device
On Fri, 18 Sep 2020 13:09:25 -0400
Tony Krowiak wrote:
>
>
> On 9/17/20 10:34 AM, Cornelia Huck wrote:
> > On Fri, 21 Aug 2020 15:56:07 -0400
> > Tony Krowiak wrote:
> >
> >> The matrix of adapters and domains configured in a guest's CRYCB may
> >> differ from the matrix of adapters and
On Fri, 21 Aug 2020 15:56:06 -0400
Tony Krowiak wrote:
> The APCB is a field within the CRYCB that provides the AP configuration
> to a KVM guest. Let's introduce a shadow copy of the KVM guest's APCB and
> maintain it for the lifespan of the guest.
>
AFAIU this is supposed to be a no change
On Fri, 25 Sep 2020 18:29:16 -0400
Tony Krowiak wrote:
>
>
> On 9/21/20 11:45 AM, Halil Pasic wrote:
> > On Fri, 18 Sep 2020 13:02:34 -0400
> > Tony Krowiak wrote:
> >
> >> Attempting to unregister Guest Interruption Subclass (GISC) when the
> >>
On Fri, 21 Aug 2020 15:56:05 -0400
Tony Krowiak wrote:
> +
> +bool vfio_ap_mdev_resource_in_use(unsigned long *apm, unsigned long *aqm)
> +{
> + bool in_use;
> +
> + mutex_lock(_dev->lock);
> + in_use = !!vfio_ap_mdev_verify_no_sharing(NULL, apm, aqm);
> +
On Fri, 21 Aug 2020 15:56:04 -0400
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 callback is to provide a driver with the means to prevent a root user
> from
On Fri, 21 Aug 2020 15:56:03 -0400
Tony Krowiak wrote:
> Let's create links between each queue device bound to the vfio_ap device
How about: Let us establish a bidirectional link...
we kind of had a shaky queue --> matrix_mdev link prior to this patch,
you are making this one solid and you are
On Fri, 21 Aug 2020 15:56:02 -0400
Tony Krowiak wrote:
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -26,43 +26,26 @@
>
> static int vfio_ap_mdev_reset_queues(struct mdev_device *mdev);
>
> -static int match_apqn(struct device *dev, const void
On Thu, 27 Aug 2020 10:24:07 -0400
Tony Krowiak wrote:
>
>
> On 8/25/20 6:13 AM, Cornelia Huck wrote:
> > On Fri, 21 Aug 2020 15:56:02 -0400
> > Tony Krowiak wrote:
> >
> >> This patch refactor's the vfio_ap device driver to use the AP bus's
> > s/refactor's/refactors/
>
> Of course, what
On Fri, 18 Sep 2020 13:02:34 -0400
Tony Krowiak wrote:
> Attempting to unregister Guest Interruption Subclass (GISC) when the
> link between the matrix mdev and KVM has been removed results in the
> following:
>
>"Kernel panic -not syncing: Fatal exception: panic_on_oops"
>
> This patch
On Mon, 21 Sep 2020 07:48:58 +0200
Christian Borntraeger wrote:
>
>
> On 18.09.20 19:02, Tony Krowiak wrote:
> > Attempting to unregister Guest Interruption Subclass (GISC) when the
> > link between the matrix mdev and KVM has been removed results in the
> > following:
> >
> >"Kernel
On Mon, 7 Sep 2020 11:39:05 +0200
Pierre Morel wrote:
> Hi all,
>
> The goal of the series is to give a chance to the architecture
> to validate VIRTIO device features.
Michael, is this going in via your tree?
gured device we fail it (device status field), because
attempting to drive it is a recipe for disaster.
>
> Signed-off-by: Pierre Morel
> Reviewed-by: Cornelia Huck
Reviewed-by: Halil Pasic
t set.
>
> Signed-off-by: Pierre Morel
> Reviewed-by: Cornelia Huck
Reviewed-by: Halil Pasic
[..]
>
> +config ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> + bool
> + help
> + This option is selected if the architecture may need to enforce
> + VIRTIO_F
On Thu, 9 Jul 2020 16:51:04 +0200
Pierre Morel wrote:
>
>
> On 2020-07-09 16:47, Halil Pasic wrote:
> > On Thu, 9 Jul 2020 12:51:58 +0200
> > Pierre Morel wrote:
> >
> >>>> +int arch_validate_virtio_features(struct virtio_device *dev)
> &g
On Thu, 9 Jul 2020 12:51:58 +0200
Pierre Morel wrote:
> >> +int arch_validate_virtio_features(struct virtio_device *dev)
> >> +{
> >> + if (!is_prot_virt_guest())
> >> + return 0;
> >> +
> >> + if (!virtio_has_feature(dev, VIRTIO_F_VERSION_1)) {
> >> + dev_warn(>dev, "device
On Thu, 9 Jul 2020 10:39:18 +0200
Pierre Morel wrote:
> An architecture may need to validate the VIRTIO devices features
> based on architecture specifics.
>
> Signed-off-by: Pierre Morel
> Reviewed-by: Cornelia Huck
> Acked-by: Christian Borntraeger
Ack
gt; +"device must provide VIRTIO_F_IOMMU_PLATFORM\n");
>
> "support for limited memory access required for protected
> virtualization"
>
> ?
>
> Mentioning the feature flag is shorter in both cases, though.
I liked the messages in v4. Why did we change those? Did somebody
complain?
I prefer the old ones, but it any case:
Acked-by: Halil Pasic
>
> > + return -ENODEV;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > /* protected virtualization */
> > static void pv_init(void)
> > {
>
> Either way,
>
> Reviewed-by: Cornelia Huck
>
On Tue, 7 Jul 2020 12:38:17 +0200
Pierre Morel wrote:
>
>
> On 2020-07-07 11:46, Cornelia Huck wrote:
> > On Tue, 7 Jul 2020 10:44:37 +0200
> > Pierre Morel wrote:
> >
> >> S390, protecting the guest memory against unauthorized host access
> >> needs to enforce VIRTIO I/O device protection
On Fri, 19 Jun 2020 11:20:51 +0200
Cornelia Huck wrote:
> > > + if (arch_needs_virtio_iommu_platform(dev) &&
> > > + !virtio_has_feature(dev, VIRTIO_F_IOMMU_PLATFORM)) {
> > > + dev_warn(>dev,
> > > + "virtio: device must provide
> > >
f preventing calamity, and the details can be changed any time,
thus:
Acked-by: Halil Pasic
Regarding the interaction of architecture specific code with virtio core,
I believe we could have made the interface more generic.
One option is to introduce virtio_arch_finalize_features(), a hook that
cou
On Tue, 16 Jun 2020 12:52:50 +0200
Pierre Morel wrote:
> >> int virtio_finalize_features(struct virtio_device *dev)
> >> {
> >>int ret = dev->config->finalize_features(dev);
> >> @@ -179,6 +184,10 @@ int virtio_finalize_features(struct virtio_device
> >> *dev)
> >>if
On Mon, 15 Jun 2020 14:39:24 +0200
Pierre Morel wrote:
I find the subject (commit short) sub optimal. The 'arch' is already
accepting devices 'without IOMMU feature'. What you are introducing is
the ability to reject.
> An architecture protecting the guest memory against unauthorized host
>
On Mon, 15 Jun 2020 11:01:55 +0800
Jason Wang wrote:
> > hum, in between I found another way which seems to me much better:
> >
> > We already have the force_dma_unencrypted() function available which
> > AFAIU is what we want for encrypted memory protection and is already
> > used by power
On Wed, 10 Jun 2020 15:11:51 +0200
Pierre Morel wrote:
> Protected Virtualisation protects the memory of the guest and
> do not allow a the host to access all of its memory.
>
> Let's refuse a VIRTIO device which does not use IOMMU
> protected access.
>
Should we ever get a virtio-ccw device
On Tue, 28 Apr 2020 12:57:12 +0200
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 Pasic wrote:
> >>> On Mon, 27 Apr 20
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.20 05:57, Halil Pasic wrote:
> >>> On Tue, 7 A
On Fri, 13 Sep 2019 17:26:48 -0400
Tony Krowiak wrote:
> The current design for AP pass-through does not support making dynamic
> changes to the AP matrix of a running guest resulting in three deficiencies
> this patch series is intended to mitigate:
>
> 1. Adapters, domains and control domains
m ZONE_DMA (31 bit addressable) or any DMA capable
memory will do, let us use coherent_dma_mask (which is used for
allocations) to force allocating form ZONE_DMA while changing dma_mask
to DMA_BIT_MASK(64) so that at least the streaming API will regard
the whole memory DMA capable.
Signed-off-by: H
On Mon, 30 Sep 2019 16:56:07 +0200
Christoph Hellwig wrote:
> The code looks fine, but I still very much disagree with the workaround
> comments. The different mask for allocations vs streaming mappings is
> exactly how the DMA API is intended to work.
Thanks for having a look! I already
m ZONE_DMA (31 bit addressable) or any DMA capable
memory will do, let us use coherent_dma_mask (which is used for
allocations) to force allocating form ZONE_DMA while changing dma_mask
to DMA_BIT_MASK(64) so that at least the streaming API will regard
the whole memory DMA capable.
Signed-off-by: H
On Fri, 13 Sep 2019 17:26:52 -0400
Tony Krowiak wrote:
> +static void vfio_ap_mdev_get_crycb_matrix(struct ap_matrix_mdev *matrix_mdev)
> +{
> + unsigned long apid, apqi;
> + unsigned long masksz = BITS_TO_LONGS(AP_DEVICES) *
> +sizeof(unsigned long);
> +
> +
On Fri, 13 Sep 2019 17:26:52 -0400
Tony Krowiak wrote:
> +static void vfio_ap_mdev_get_crycb_matrix(struct ap_matrix_mdev *matrix_mdev)
> +{
> + unsigned long apid, apqi;
> + unsigned long masksz = BITS_TO_LONGS(AP_DEVICES) *
> +sizeof(unsigned long);
> +
> +
On Thu, 5 Sep 2019 12:26:15 -0400
Tony Krowiak wrote:
> On 8/30/19 12:02 PM, Halil Pasic wrote:
[..]
> >> @@ -1177,7 +1179,18 @@ static int vfio_ap_mdev_reset_queues(struct
> >> mdev_device *mdev)
> >> */
> >>if (
and it certainly should also have an
> > agreement from
> > Anthony.
> >
> > On 30.08.19 18:02, Halil Pasic wrote:
> >> From: Halil Pasic
> >> Date: Fri, 30 Aug 2019 17:39:47 +0200
> >> Subject: [PATCH 2/2] s390: vfio-ap: don't wait after AQIC interpretation
s it is in LPAR.
Sure I can send a separate patch and state in the cover lette that it
builds on top of 'vfio-ap: remove unnecessary calls to disable queue
interrupts'.
And yes the commit message is sloppy. Was not meant to end up in the
changelog. Just a quick and dirty explanation.
> On 30.08.
The intention seems to be to warn once when we don't wait enough for the
reset to complete. Let's use the right retry counter to accomplish that
semantic.
Signed-off-by: Halil Pasic
---
drivers/s390/crypto/vfio_ap_ops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
afe
to assume that NIB and GISA won't be poked by HW offline as the guys
without documentation can't contribute.
Two issues not directly related to your patch. I formulated those as two
follow up patches on top of yours .please take a look at them.
---8<---
On Thu, 18 Jul 2019 11:04:17 +0200
Cornelia Huck wrote:
> On Wed, 17 Jul 2019 19:27:25 +0200
> Halil Pasic wrote:
>
> > On Wed, 15 May 2019 15:27:03 -0400
> > Vivek Goyal wrote:
> >
> > > From: Stefan Hajnoczi
> > >
> > > Setup a d
On Wed, 15 May 2019 15:27:03 -0400
Vivek Goyal wrote:
> From: Stefan Hajnoczi
>
> Setup a dax device.
>
> Use the shm capability to find the cache entry and map it.
>
> The DAX window is accessed by the fs/dax.c infrastructure and must have
> struct pages (at least on x86). Use
On Fri, 12 Jul 2019 18:55:47 -0300
Thiago Jung Bauermann wrote:
>
> [ Cc'ing Tom Lendacky which I forgot to do earlier. Sorry about that. ]
>
> Hello Halil,
>
> Thanks for the quick review.
>
> Halil Pasic writes:
>
> > On Fri, 12 Jul 2019 02:36:31 -0300
On Fri, 12 Jul 2019 16:08:12 +0200
Christoph Hellwig wrote:
> On Fri, Jul 12, 2019 at 03:09:12PM +0200, Halil Pasic wrote:
> > This is the implementation for the guys that don't
> > have ARCH_HAS_MEM_ENCRYPT.
> >
> > Means sev_active() may not be used in such code
On Thu, 13 Jun 2019 15:39:33 -0400
Tony Krowiak wrote:
> The current design for AP pass-through does not support making dynamic
> changes to the AP matrix of a running guest
Sorry guys, I currently don't have the bandwidth to participate in this
discussion. Please proceed without me ;)
On Tue, 21 May 2019 17:34:33 +0200
Pierre Morel wrote:
> This patch series implements PQAP/AQIC interception in KVM.
Thanks, applied
On Tue, 25 Jun 2019 22:13:12 +0200
Christian Borntraeger wrote:
>
>
> On 21.05.19 17:34, Pierre Morel wrote:
> > AP Queue Interruption Control (AQIC) facility gives
> > the guest the possibility to control interruption for
> > the Cryptographic Adjunct Processor queues.
> >
> > Signed-off-by:
well, so
> > that we can easily extend the 'driverctl' tool (which makes
> > use of the driver_override attribute for pci).
> >
> > Note that unlike pci we still require a driver override to
> > match the subchannel type; matching more than one subchannel
> > t
On Tue, 11 Jun 2019 10:37:55 -0400
Tony Krowiak wrote:
> On 6/7/19 10:29 AM, Halil Pasic wrote:
> > On Tue, 4 Jun 2019 15:38:51 -0400
> > Tony Krowiak wrote:
[..]
> >>> +static void vfio_ap_wait_for_irqclear(int apqn)
> >>> +{
> >>> + s
On Tue, 4 Jun 2019 15:38:51 -0400
Tony Krowiak wrote:
> On 5/21/19 11:34 AM, Pierre Morel wrote:
> > We register a AP PQAP instruction hook during the open
> > of the mediated device. And unregister it on release.
[..]
> > +/**
> > + * vfio_ap_wait_for_irqclear
> > + * @apqn: The AP Queue
On Thu, 23 May 2019 11:36:12 -0400
Tony Krowiak wrote:
> On 5/21/19 11:34 AM, Pierre Morel wrote:
> > This patch series implements PQAP/AQIC interception in KVM.
> >
[..]
> >
> > Tony, I did not rebase this series above the dynamic configuration
> > patches because:
> > - This series do the
On Thu, 9 May 2019 18:26:59 +0200
Pierre Morel wrote:
> On 09/05/2019 11:06, Cornelia Huck wrote:
> > [vfio-ap folks: find a question regarding removal further down]
> >
> > On Wed, 8 May 2019 22:06:48 +
> > Parav Pandit wrote:
> >
> >>> -Original Message-
> >>> From: Cornelia
> @@ -4,6 +4,7 @@
> *
> * Author(s): Tony Krowiak
> * Halil Pasic
> + * Pierre Morel
> *
> * Copyright IBM Corp. 2018
> */
> @@ -90,4 +91,14 @@ struct ap_matrix_mdev {
> extern int vfio_ap_mdev_register(void);
> extern void vfio_ap_md
On Fri, 26 Apr 2019 15:01:27 +0200
Pierre Morel wrote:
> +/**
> + * vfio_ap_clrirq: Disable Interruption for a APQN
> + *
> + * @dev: the device associated with the ap_queue
> + * @q: the vfio_ap_queue holding AQIC parameters
> + *
> + * Issue the host side PQAP/AQIC
> + * On success: unpin
On Tue, 30 Apr 2019 10:32:52 +0200
Pierre Morel wrote:
> >>> + aqic_gisa.gisa = gisa->next_alert >> 4;
> >>
> >> Why gisa->next_alert? Isn't this supposed to get set to gisa origin
> >> (without some bits on the left)?
s/left/right/
> >
> > Someone already asked this question.
It must
On Tue, 30 Apr 2019 09:59:51 +0200
Pierre Morel wrote:
> On 29/04/2019 18:07, Halil Pasic wrote:
> > On Fri, 26 Apr 2019 15:01:26 +0200
> > Pierre Morel wrote:
> >
> >> @@ -858,7 +887,17 @@ static int vfio_ap_mdev_open(struct mdev_device *md
On Fri, 26 Apr 2019 15:01:27 +0200
Pierre Morel wrote:
> +static struct ap_queue_status vfio_ap_setirq(struct vfio_ap_queue *q)
> +{
> + struct ap_qirq_ctrl aqic_gisa = {};
> + struct ap_queue_status status = {};
> + struct kvm_s390_gisa *gisa;
> + struct kvm *kvm;
> +
On Fri, 26 Apr 2019 15:01:26 +0200
Pierre Morel wrote:
> @@ -858,7 +887,17 @@ static int vfio_ap_mdev_open(struct mdev_device *mdev)
> return ret;
> }
>
> - return 0;
> + matrix_mdev->iommu_notifier.notifier_call = vfio_ap_mdev_iommu_notifier;
> + events =
On Sat, 20 Apr 2019 17:49:39 -0400
Tony Krowiak wrote:
> +void vfio_ap_mdev_probe_queue(unsigned long apid, unsigned long apqi)
> +{
> + struct ap_matrix_mdev *matrix_mdev;
> +
> + matrix_mdev = vfio_ap_mdev_find_matrix_mdev(apid, apqi);
> +
> + /*
> + * If the queue is assigned
On Mon, 15 Apr 2019 18:43:24 -0400
Tony Krowiak wrote:
> On 4/15/19 2:59 PM, Halil Pasic wrote:
> > On Mon, 15 Apr 2019 12:51:23 -0400
> > Tony Krowiak wrote:
> >
> >> Having said that, I understand your concern about a driver hogging
> >> reso
On Mon, 15 Apr 2019 12:51:23 -0400
Tony Krowiak wrote:
> Having said that, I understand your concern about a driver hogging
> resources. I think I can provide a solution that serves both the
> purpose of preventing problems associated with accidental removal
> of AP resources as well as allowing
On Tue, 19 Mar 2019 15:47:05 +0100
Pierre Morel wrote:
> > if (matrix_mdev->kvm)
> > kvm_arch_crypto_clear_masks(matrix_mdev->kvm);
>
> This still conditional?
> >>>
> >>> Yes, nothing to clear if there is no KVM.
> >>>
> >>
> >> Since we have ensured
On Tue, 19 Mar 2019 11:01:44 +0100
Pierre Morel wrote:
> On 15/03/2019 18:28, Halil Pasic wrote:
[..]
> >
> > Things get complicated when one considers that ECA.28 is an effective
> > control.
>
> I don't think so, ECA_28 is not really a problem.
> We do
On Tue, 19 Mar 2019 10:38:42 +0100
Pierre Morel wrote:
> On 15/03/2019 19:15, Halil Pasic wrote:
> > On Wed, 13 Mar 2019 17:05:01 +0100
> > Pierre Morel wrote:
> >
> >> When the mediated device is open we setup the relation with KVM unset it
> >&g
On Wed, 13 Mar 2019 17:05:01 +0100
Pierre Morel wrote:
> When the mediated device is open we setup the relation with KVM unset it
> when the mediated device is released.
>
> We ensure KVM is present on opening of the mediated device.
>
> We ensure that KVM survives the mediated device, and
On Fri, 15 Mar 2019 15:10:25 +0100
Pierre Morel wrote:
> Sorry, wrong conclusion, handling this in userland will bring us much
> too far if we want to answer correctly for the case the hook is not
> there but QEMU accepted the facility for AQIC.
>
> The alternative is easier, we just continue
On Fri, 15 Mar 2019 14:26:34 +0100
Pierre Morel wrote:
> On 15/03/2019 11:20, Cornelia Huck wrote:
> > On Wed, 13 Mar 2019 17:04:58 +0100
> > Pierre Morel wrote:
> >
> >> +/*
> >> + * handle_pqap: Handling pqap interception
> >> + * @vcpu: the vcpu having issue the pqap instruction
> >> + *
>
On Fri, 22 Feb 2019 16:29:56 +0100
Pierre Morel wrote:
> We need to associate the ap_vfio_queue, which will hold the
> per queue information for interrupt with a matrix mediated device
> which hold the configuration and the way to the CRYCB.
[..]
> +static int vfio_ap_get_all_domains(struct
On Fri, 22 Feb 2019 16:29:58 +0100
Pierre Morel wrote:
> We register the AP PQAP instruction hook during the open
> of the mediated device. And unregister it on release.
>
> In the AP PQAP instruction hook, if we receive a demand to
> enable IRQs,
> - we retrieve the vfio_ap_queue based on the
On Thu, 28 Feb 2019 09:48:39 +0100
Pierre Morel wrote:
> On 28/02/2019 09:23, Christian Borntraeger wrote:
> > On 22.02.2019 16:29, Pierre Morel wrote:
> >> To be able to use the VFIO interface to facilitate the
> >> mediated device memory pining/unpining we need to register
> >> a notifier for
On Thu, 28 Feb 2019 15:12:16 +0100
Pierre Morel wrote:
> On 28/02/2019 13:39, Halil Pasic wrote:
> > On Thu, 28 Feb 2019 10:42:23 +0100
> > Christian Borntraeger wrote:
[..]
> >> Correct?
> >
> > IMHO mostly.
> >
> > I also doing t
On Fri, 22 Feb 2019 16:29:53 +0100
Pierre Morel wrote:
> This patch implement PQAP/AQIC interception in KVM.
>
> To implement this we need to add a new structure, vfio_ap_queue,to be
> able to retrieve the mediated device associated with a queue and specific
> values needed to
On Thu, 28 Feb 2019 14:47:35 +0100
Pierre Morel wrote:
> On 28/02/2019 14:44, Christian Borntraeger wrote:
> >
> >
> > On 28.02.2019 14:23, Pierre Morel wrote:
> >> On 28/02/2019 10:42, Christian Borntraeger wrote:
> >>>
> >>>
> >>> On 27.02.2019 19:00, Tony Krowiak wrote:
> On 2/27/19
On Thu, 28 Feb 2019 10:42:23 +0100
Christian Borntraeger wrote:
>
>
> On 27.02.2019 19:00, Tony Krowiak wrote:
> > On 2/27/19 3:09 AM, Pierre Morel wrote:
> >> On 26/02/2019 16:47, Tony Krowiak wrote:
> >>> On 2/26/19 6:47 AM, Pierre Morel wrote:
> On 25/02/2019 19:36, Tony Krowiak wrote:
en two
pre-existing entities. But this change actually introduces the vfio_bus.
I would prefer something like "introduce vfio_ap bus".
I don't feel strongly about it.
Regards,
Halil
>
> > Reported-by: Marc Hartmayer
> > Reported-by: Christian Borntraeger
>
On Wed, 20 Feb 2019 10:27:31 +0100
Cornelia Huck wrote:
> On Tue, 19 Feb 2019 22:31:17 +0100
> Pierre Morel wrote:
>
> > On 19/02/2019 19:52, Tony Krowiak wrote:
> > > On 2/18/19 1:08 PM, Pierre Morel wrote:
> > >> Libudev relies on having a subsystem link for non-root devices. To
> > >>
On Thu, 14 Feb 2019 14:51:07 +0100
Pierre Morel wrote:
> We register the AP PQAP instruction hook during the open
> of the mediated device. And unregister it on release.
>
> In the AP PQAP instruction hook, if we receive a demand to
> enable IRQs,
> - we retrieve the vfio_ap_queue based on the
> +
> +static struct bus_type matrix_bus = {
> + .name = "vfio_ap",
> + .match = _bus_match,
> +};
> +
> +static int matrix_probe(struct device *dev)
> +{
> + return 0;
> +}
> +
> +static struct device_driver matrix_driver = {
> + .name = "vfio_ap",
> + .bus = _bus,
> + .probe = matrix_probe,
> +};
> +
With the changes suggested by Christian:
Acked-by: Halil Pasic
[..]
On Fri, 15 Feb 2019 17:55:35 -0500
Tony Krowiak wrote:
> On 2/14/19 8:51 AM, Pierre Morel wrote:
> > To be able to use the VFIO interface to facilitate the
> > mediated device memory pining/unpining we need to register
> > a notifier for IOMMU.
> >
> > Signed-off-by: Pierre Morel
> > ---
> >
sage I see is triggered by
KVM_DEV_FLIC_CLEAR_IRQS. And in that context this seems appropriate.
However gisa can hold other stuff than the ipm, and in that sense
the name kvm_s390_gisa_clear() may be misleading. I ask myself
questions like who would need to reset simm and nimm on system
reset.
Morel
> Reviewed-by: Cornelia Huck
Acked-by: Halil Pasic
On Tue, 29 Jan 2019 16:29:40 +0100
Michael Mueller wrote:
>
>
> On 29.01.19 14:26, Halil Pasic wrote:
> > On Thu, 24 Jan 2019 13:59:38 +0100
> > Michael Mueller wrote:
> >
> >> The patch implements a handler for GIB alert interruptions
> >
On Tue, 29 Jan 2019 16:47:10 +0100
Michael Mueller wrote:
>
>
> On 29.01.19 14:22, Cornelia Huck wrote:
> > On Mon, 28 Jan 2019 17:50:54 +0100
> > Halil Pasic wrote:
> >
> >> On Thu, 24 Jan 2019 13:59:33 +0100
> >> Michael Mueller wrote:
On Thu, 24 Jan 2019 13:59:39 +0100
Michael Mueller wrote:
> By initializing the GIB, it will be used by the kvm host.
>
> Signed-off-by: Michael Mueller
> Reviewed-by: Pierre Morel
Reviewed-by: Halil Pasic
end up waiting here, I guess, it's likely that a new
timer is going to get set up right after we do
gisa->next_alert = (u32)(u64)gisa;
in process_gib_alert_list().
> + gi->origin = NULL;
> }
>
> /**
> @@ -3037,11 +3187,23 @@ int kvm_s390_gisc_unregister(struct kvm *kvm, u32
> gisc)
> }
> EXPORT_SYMBOL_GPL(kvm_s390_gisc_unregister);
>
Overall, there are couple of things I would prefer done differently,
but better something working today that something prefect in 6 months.
In that sense, provided my comment regarding destroy is addressed:
Acked-by: Halil Pasic
a gisa in
> gib alert interruption context.
>
> Signed-off-by: Michael Mueller
> Reviewed-by: Pierre Morel
> Reviewed-by: Cornelia Huck
> Reviewed-by: David Hildenbrand
Reviewed-by: Halil Pasic
[..]
f the names.
Another idea for later would be to sanity check in gisa destroy that
alert.mask is back to all zero -- to catch any corresponding driver
bugs.
Acked-by: Halil Pasic
>
> Signed-off-by: Michael Mueller
[..]
> static inline void gisa_set_ipm_gisc(struct kvm_s390_gisa *gisa
this series.
>
> Signed-off-by: Michael Mueller
> Reviewed-by: Janosch Frank
> Reviewed-by: Christian Borntraeger
> Reviewed-by: Cornelia Huck
> Reviewed-by: Pierre Morel
I don't agree with the commit message to 100%, but I'd rather not start
a discussion.
Acked-by: Halil Pasic
[..]
101 - 200 of 392 matches
Mail list logo
