On Tue, 9 Jun 2020 17:47:47 +0200
Claudio Imbrenda wrote:
> On Tue, 9 Jun 2020 11:41:30 +0200
> Halil Pasic wrote:
>
> [...]
>
> > I don't know. Janosch could answer that, but he is on vacation. Adding
> > Claudio maybe he can answer. My understanding is, tha
On Tue, 9 Jun 2020 12:16:41 +0200
Cornelia Huck wrote:
> On Sun, 7 Jun 2020 13:07:35 +1000
> David Gibson wrote:
>
> > On Sat, Jun 06, 2020 at 04:21:31PM -0400, Michael S. Tsirkin wrote:
> > > On Thu, May 21, 2020 at 01:43:04PM +1000, David Gibson wrote:
> > > > The default behaviour for virt
On Sat, 6 Jun 2020 18:44:09 +1000
David Gibson wrote:
> On Fri, Jun 05, 2020 at 12:55:05PM +0200, Cornelia Huck wrote:
> > On Thu, 21 May 2020 13:42:46 +1000
> > David Gibson wrote:
> >
> > > A number of hardware platforms are implementing mechanisms whereby the
> > > hypervisor does not have u
On Tue, 9 Jun 2020 08:44:02 +0200
Cornelia Huck wrote:
> On Mon, 8 Jun 2020 19:00:45 +0200
> Halil Pasic wrote:
>
>
> > > I'm also not 100% sure about migration... would it make sense to
> > > discuss all of this in the context of the cross-arch patchse
k at that. What I think special
about s390 is that F_ACCESS_PLATFORM is hurting us because all IO needs
to go through ZONE_DMA (this is a problem of the implementation that
stemming form a limitation of the DMA API, upstream didn't let me
fix it).
> >
> > Further improvements ar
On Wed, 20 May 2020 12:23:24 -0400
"Michael S. Tsirkin" wrote:
> On Fri, May 15, 2020 at 12:11:55AM +0200, Halil Pasic wrote:
> > The virtio specification tells that the device is to present
> > VIRTIO_F_ACCESS_PLATFORM (a.k.a. VIRTIO_F_IOMMU_PLATFORM) when the
&g
On Fri, 5 Jun 2020 12:45:35 +0200
Cornelia Huck wrote:
> On Thu, 21 May 2020 13:43:04 +1000
> David Gibson wrote:
>
> > The default behaviour for virtio devices is not to use the platforms normal
> > DMA paths, but instead to use the fact that it's running in a hypervisor
> > to directly access
On Thu, 28 May 2020 16:42:49 +0200
Janosch Frank wrote:
> On 5/28/20 1:21 PM, Cornelia Huck wrote:
> >> I think we have "allow protected" already expressed via cpu models. I'm
> >> also not sure how libvirt would react to the idea of a new machine
> >> property for this. You did mean "allow prote
On Thu, 28 May 2020 13:21:12 +0200
Cornelia Huck wrote:
> On Fri, 22 May 2020 23:04:51 +0200
> Halil Pasic wrote:
>
> > On Wed, 20 May 2020 12:23:24 -0400
> > "Michael S. Tsirkin" wrote:
[..]
> > > So, how about this: switch iommu to on/off/auto.
On Wed, 20 May 2020 12:23:24 -0400
"Michael S. Tsirkin" wrote:
> On Fri, May 15, 2020 at 12:11:55AM +0200, Halil Pasic wrote:
> > The virtio specification tells that the device is to present
> > VIRTIO_F_ACCESS_PLATFORM (a.k.a. VIRTIO_F_IOMMU_PLATFORM) when the
&g
On Fri, 15 May 2020 00:11:55 +0200
Halil Pasic wrote:
> The virtio specification tells that the device is to present
> VIRTIO_F_ACCESS_PLATFORM (a.k.a. VIRTIO_F_IOMMU_PLATFORM) when the
> device "can only access certain memory addresses with said access
> specified and/or grante
important).
Let us manage the VIRTIO_F_ACCESS_PLATFORM virtio feature automatically
for virtio-ccw devices, i.e. force it before we start the protected VM.
If the VM should cease to be protected, the original value is restored.
Signed-off-by: Halil Pasic
---
NOTES:
* Doing more system_resets() is
On Fri, 27 Mar 2020 17:46:20 +0100
Igor Mammedov wrote:
> On Fri, 27 Mar 2020 17:05:34 +0100
> Christian Borntraeger wrote:
>
> > On 27.03.20 17:01, David Hildenbrand wrote:
> > > On 27.03.20 16:34, Christian Borntraeger wrote:
> > >>
> > >>
> > >> On 27.03.20 16:29, David Hildenbrand wrote:
On Tue, 24 Mar 2020 18:04:30 +0100
Cornelia Huck wrote:
> On Thu, 6 Feb 2020 22:45:03 +0100
> Eric Farman wrote:
>
> > From: Farhan Ali
> >
> > EIO is returned by vfio-ccw mediated device when the backing
> > host subchannel is not operational anymore. So return cc=3
> > back to the guest, r
On Fri, 20 Mar 2020 18:25:18 +0100
Cornelia Huck wrote:
> On Fri, 20 Mar 2020 15:31:01 +0100
> Halil Pasic wrote:
>
> > In update_machine_ipl_properties() the array ascii_loadparm needs to
> > hold the 8 char lodparm and a string terminating zero char.
>
> s/lod
On Thu, 19 Mar 2020 18:31:11 +0100
David Hildenbrand wrote:
> [...]
>
> >>
> >> I asked this question already to Michael (cc) via a different
> >> channel, but hare is it again:
> >>
> >> Why does the balloon driver not support VIRTIO_F_IOMMU_PLATFORM? It
> >> is absolutely not clear to me. The
In update_machine_ipl_properties() the array ascii_loadparm needs to
hold the 8 char lodparm and a string terminating zero char.
Let's increase the size of ascii_loadparm accordingly.
Signed-off-by: Halil Pasic
Fixes: 0a01e082a4 ("s390/ipl: sync back loadparm")
Reported-by
On Fri, 20 Mar 2020 10:23:03 +0100
Christian Borntraeger wrote:
>
>
> On 19.03.20 21:31, Peter Maydell wrote:
> > On Tue, 10 Mar 2020 at 15:09, Christian Borntraeger
> > wrote:
> >>
> >> From: Halil Pasic
> >>
> >> We expose load
On Thu, 19 Mar 2020 14:54:11 +0100
David Hildenbrand wrote:
> On 27.02.20 13:24, Halil Pasic wrote:
> > On Wed, 26 Feb 2020 16:11:03 +0100
> > Janosch Frank wrote:
> >
> >> On 2/26/20 3:59 PM, David Hildenbrand wrote:
> >>> On 26.02.20 13:20, Janosch F
On Thu, 27 Feb 2020 13:24:02 +0100
Halil Pasic wrote:
> On Wed, 26 Feb 2020 16:11:03 +0100
> Janosch Frank wrote:
>
> > On 2/26/20 3:59 PM, David Hildenbrand wrote:
> > > On 26.02.20 13:20, Janosch Frank wrote:
> > >> Ballooning in protected VMs can on
On Fri, 13 Mar 2020 12:31:22 -0400
Peter Xu wrote:
> On Fri, Mar 13, 2020 at 11:29:59AM -0400, Michael S. Tsirkin wrote:
> > On Fri, Mar 13, 2020 at 01:44:46PM +0100, Halil Pasic wrote:
> > > [..]
> > > > >
> > > > > CCing Tom. @Tom do
[..]
> >
> > CCing Tom. @Tom does vhost-vsock work for you with SEV and current qemu?
> >
> > Also, one can specify iommu_platform=on on a device that ain't a part of
> > a secure-capable VM, just for the fun of it. And that breaks
> > vhost-vsock. Or is setting iommu_platform=on only valid if
>
On Mon, 9 Mar 2020 14:44:20 +0100
David Hildenbrand wrote:
> On 09.03.20 14:32, Halil Pasic wrote:
> > We expose loadparm as a r/w machine property, but if loadparm is set by
> > the guest via DIAG 308, we don't update the property. Having a
> > disconnect between t
(see 789b5a401b "s390: Ensure IPL from SCSI works as
expected" for details) we call s390_gen_initial_iplb() on resets
effectively overwriting the guest/user supplied loadparm with the stale
value.
Signed-off-by: Halil Pasic
Fixes: 7104bae9de ("hw/s390x: provide loadparm property for the m
On Thu, 5 Mar 2020 17:21:44 +0100
Christian Borntraeger wrote:
>
>
> On 05.03.20 15:25, Christian Borntraeger wrote:
> >
> >
> > On 05.03.20 15:11, Halil Pasic wrote:
> >> On Thu, 5 Mar 2020 13:44:31 +0100
> >> Christian Borntraeger wrote:
>
On Thu, 5 Mar 2020 13:44:31 +0100
Christian Borntraeger wrote:
>
>
> On 25.02.20 15:35, Viktor Mihajlovski wrote:
> >
> >
> > On 2/25/20 12:56 PM, Halil Pasic wrote:
> >> On Tue, 25 Feb 2020 10:39:40 +0100
> >> David Hildenbrand wrote:
&g
On Thu, 27 Feb 2020 10:47:22 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Feb 27, 2020 at 02:02:15PM +0100, Halil Pasic wrote:
> > On Wed, 26 Feb 2020 11:52:26 -0500
> > "Michael S. Tsirkin" wrote:
> >
> > > On Wed, Feb 26, 2020 at 04:36:18P
On Wed, 26 Feb 2020 11:52:26 -0500
"Michael S. Tsirkin" wrote:
> On Wed, Feb 26, 2020 at 04:36:18PM +0100, Halil Pasic wrote:
> > On Wed, 26 Feb 2020 08:37:13 -0500
> > "Michael S. Tsirkin" wrote:
> >
> > > On Wed, Feb 26, 2020 at 02:28:39P
e we'll
> rather try to automatically enable the IOMMU for all devices when
> switching into protected mode. He said that if the IOMMU is set the
> balloon code will do an early exit on feature negotiation.
>
I have a discussion starter RFC for you.
--8<---
On Wed, 26 Feb 2020 08:37:13 -0500
"Michael S. Tsirkin" wrote:
> On Wed, Feb 26, 2020 at 02:28:39PM +0100, Halil Pasic wrote:
> > On Wed, 26 Feb 2020 17:43:57 +0800
> > Jason Wang wrote:
> >
> > > We turn on device IOTLB via VIRTIO_F_IOMMU_PLATFORM u
evice is backed by IOMMU and disable
> device IOTLB.
>
> Reported-by: Halil Pasic
> Fixes: c471ad0e9bd46 ("vhost_net: device IOTLB support")
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Jason Wang
Tested-by: Halil Pasic
Reviewed-by: Halil Pasic
Thank you very much
t; > transactions which will damage the performance.
> >
> > Fixing this by check whether the device is backed by IOMMU and disable
> > device IOTLB.
> >
> > Reported-by: Halil Pasic
> > Fixes: c471ad0e9bd46 ("vhost_net: device IOTLB support")
>
r the device is backed by IOMMU and disable
> > > > device IOTLB.
> > > >
> > > > Reported-by: Halil Pasic
> > > > Fixes: c471ad0e9bd46 ("vhost_net: device IOTLB support")
> > > Well it's just an optimization, isn't it?
On Tue, 25 Feb 2020 10:39:40 +0100
David Hildenbrand wrote:
> On 24.02.20 16:02, Halil Pasic wrote:
> > We expose loadparm as a r/w machine property, but if loadparm is set by
> > the guest via DIAG 308, we don't update the property. Having a
> > disconnect between t
(see 789b5a401b "s390: Ensure IPL from SCSI works as
expected" for details) we call s390_gen_initial_iplb() on resets
effectively overwriting the guest/user supplied loadparm with the stale
value.
Signed-off-by: Halil Pasic
Fixes: 7104bae9de "hw/s390x: provide loadparm property for the
On Thu, 6 Feb 2020 14:15:53 +0100
Igor Mammedov wrote:
> > Tested-by: Halil Pasic
> > Acked-by: Halil Pasic
> Thanks,
>
> Could you also take a look at patches 3-7/8o that makes this possible?
> (it never hurts to have second pair of eyes on a code that affects
>
y-backend-file,id=mem
-machine type=s390-ccw-virtio,memory-backend=mem
a spin on s390x. Seems to largely work a expected. So I guess it is:
Tested-by: Halil Pasic
Acked-by: Halil Pasic
Thanks!
Halil
> ---
> CC: pa...@linux.ibm.com
> ---
> hw/s390x/s390-virtio-ccw.c | 7 +++
On Tue, 28 Jan 2020 13:07:40 +0100
Igor Mammedov wrote:
> On Mon, 27 Jan 2020 15:41:45 +0100
> Halil Pasic wrote:
>
> > On Mon, 27 Jan 2020 08:39:25 +0100
> > Igor Mammedov wrote:
[..]
> > >
> > > one should be able to use memory-backend prope
On Mon, 27 Jan 2020 08:39:25 +0100
Igor Mammedov wrote:
> On Fri, 24 Jan 2020 20:17:48 +0100
> Halil Pasic wrote:
>
> > On Thu, 23 Jan 2020 12:38:43 +0100
> > Igor Mammedov wrote:
> >
> > > With main RAM now converted to hostmem backends, there
On Thu, 23 Jan 2020 12:38:43 +0100
Igor Mammedov wrote:
> With main RAM now converted to hostmem backends, there is no
> point in keeping global mem_prealloc around, so alias
> -mem-prealloc to "memory-backend.prealloc=on"
> machine compat[*] property and make mem_prealloc a local
> variable to
On Mon, 2 Dec 2019 17:40:07 +0100
Cornelia Huck wrote:
> On Sat, 30 Nov 2019 20:42:39 +0100
> Markus Armbruster wrote:
>
> > Cc: Halil Pasic
> > Cc: Cornelia Huck
> > Cc: Christian Borntraeger
> > Signed-off-by: Markus Armbruster
> > ---
> > h
On Thu, 28 Nov 2019 12:03:01 -0500
"Michael S. Tsirkin" wrote:
[..]
> >
> > But it keeps nagging me, is it really OK for the device to access the
> > virtio ring during reset? My intuition tells me that the device should
> > not look for new requests after it has been told to reset.
>
>
> Wel
On Tue, 19 Nov 2019 18:50:03 -0600
Michael Roth wrote:
[..]
> I.e. the calling code is only scheduling a one-shot BH for
> virtio_blk_data_plane_stop_bh, but somehow we end up trying to process
> an additional virtqueue entry before we get there. This is likely due
> to the following check in vir
On Tue, 19 Nov 2019 13:02:20 +0100
Cornelia Huck wrote:
> On Tue, 19 Nov 2019 12:23:40 +0100
> Halil Pasic wrote:
>
> > On Mon, 18 Nov 2019 19:13:34 +0100
> > Cornelia Huck wrote:
> >
> > > > EIO is returned by vfio-ccw mediated device when the
On Mon, 18 Nov 2019 19:13:34 +0100
Cornelia Huck wrote:
> > EIO is returned by vfio-ccw mediated device when the backing
> > host subchannel is not operational anymore. So return cc=3
> > back to the guest, rather than returning a unit check.
> > This way the guest can take appropriate action suc
On Thu, 14 Nov 2019 14:19:15 +0100
Cornelia Huck wrote:
> On Thu, 14 Nov 2019 14:02:35 +0100
> Halil Pasic wrote:
>
> > On Thu, 14 Nov 2019 11:38:23 +0100
> > Cornelia Huck wrote:
> >
> > > On Wed, 13 Nov 2019 20:02:33 +0100
> > > Pierre More
On Thu, 14 Nov 2019 11:38:23 +0100
Cornelia Huck wrote:
> On Wed, 13 Nov 2019 20:02:33 +0100
> Pierre Morel wrote:
>
> Minor nit for $SUBJECT: this isn't a kvm-unit-tests patch, that's just
> one consumer :)
And subchannel is one word in s390-speak.
>
[..]
> Some questions regarding this d
m(VMSTATE_IF(ss), TYPE_S390_SKEYS, ss);
> }
> }
Acked-by: Halil Pasic
BTW what does the 'f' in VMStateIf stand for? (I've had a look
at 2/6 but didn't figure out the answer).
Regards,
Halil
+-
> hw/i386/pc_q35.c | 13 -
> hw/ppc/spapr.c | 15 +--
> hw/s390x/s390-virtio-ccw.c | 14 +-
> include/hw/boards.h| 3 +++
> include/hw/i386/pc.h | 3 +++
> 9 files changed, 71 insertions(+), 6 deletions(-)
The for s390 change:
Reviewed-by: Halil Pasic
On Wed, 26 Jun 2019 15:08:20 +0200
Cornelia Huck wrote:
> The cpu features/models are not only relevant for TCG, but
> also for KVM. Make sure that the KVM maintainers are cc:ed
> on patches as well.
>
> Signed-off-by: Cornelia Huck
Acked-by: Halil Pasic
> ---
> MA
On Thu, 11 Apr 2019 18:36:48 +0200
Cornelia Huck wrote:
> On Thu, 11 Apr 2019 12:25:38 -0400
> Eric Farman wrote:
>
> > On 4/11/19 11:58 AM, Halil Pasic wrote:
> > > On Wed, 10 Apr 2019 22:59:41 -0400
> > > Eric Farman wrote:
> > >
> > >&g
On Wed, 10 Apr 2019 22:59:41 -0400
Eric Farman wrote:
> r the next release :) It would be one thing less on my plate...
> >>
> >
> > Sorry I was not able to spend any significant amount of time on this
> > lately.
> >
> > Gave the combined set (this + Farhans fio-ccw fixes for kernel
> > stac
On Mon, 8 Apr 2019 19:07:47 +0200
Cornelia Huck wrote:
> On Mon, 8 Apr 2019 13:02:12 -0400
> Farhan Ali wrote:
>
> > On 03/01/2019 04:38 AM, Cornelia Huck wrote:
> > > When we get a solicited interrupt, the start function may have
> > > been cleared by a csch, but we still have a channel progra
; In a couple of places we copy via a local variable which is
> a technique already applied elsewhere in s390 code for this
> problem.
>
> Signed-off-by: Daniel P. Berrangé
Reviewed-by: Halil Pasic
BTW the reason for SCHIB being packed is the padding that
would emerge at the end of th
a couple of places we copy via a local variable which is
> a technique already applied elsewhere in s390 code for this
> problem.
>
> Signed-off-by: Daniel P. Berrangé
Reviewed-by: Halil Pasic
Thanks!
On Sun, 24 Mar 2019 09:09:05 +0200
Marcel Apfelbaum wrote:
> Appreciated. Let me know if you prefer me to send a V2 using the cast.
Yes, I would prefer a V2 using the cast. I think Connie should be back
next week, and can then pick your patch.
>
> Thanks for looking into it,
Thank you!
Regar
region_allocate_system_memory(ram, NULL, name, chunk);
> > >> +chunk_size = MIN(mem_size, KVM_SLOT_MAX_BYTES);
> > >> +#endif
> > >> +memory_region_allocate_system_memory(ram, NULL, name,
> > chunk_size);
> > >> memory_region_add_subregion(sysmem, offset, ram);
> > >> -mem_size -= chunk;
> > >> -offset += chunk;
> > >> +mem_size -= chunk_size;
> > >> +offset += chunk_size;
> > >> g_free(name);
> > >> name = g_strdup_printf("s390.ram.%u", ++number);
> > >> }
> > >> ---
> > >>
> > >> Anyway s390x experts will figure that out ;)
Given that I don't think there is a bug I would like any cleanup
done as a separate cleanup patch.
This snipped does seem to synchronize the formal and effective arguments
of memory_region_allocate_system_memory() and memory_region_add_subregion()
which I like, but I don't like the #ifdef stuff.
Philippe, your input is appreciated! Feel free to post a separate cleanup patch
if you like.
For the Clang issue, I think we should go with the least invasive solution.
> > >
> > > I will have a look.
> > >
I had have a look in Chirstian's stead.
My conclusion is
Reviewed-by: Halil Pasic
for the Marcel patch.
CCing Claudio who is more a memory guy than myself.
Regards,
Halil
On Wed, 13 Feb 2019 11:35:19 +0100
Cornelia Huck wrote:
> We are actually paid to look after this.
>
> Signed-off-by: Cornelia Huck
Acked-by: Halil Pasic
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINE
On Tue, 5 Feb 2019 11:18:38 +0100
Cornelia Huck wrote:
> On Mon, 4 Feb 2019 14:29:18 -0500
> Farhan Ali wrote:
>
> > On 02/04/2019 06:13 AM, Cornelia Huck wrote:
> > > On Thu, 31 Jan 2019 12:31:00 -0500
> > > Farhan Ali wrote:
> > >
> > >> On 01/29/2019 08:29 AM, Jason J. Herne wrote:
> >
On Mon, 4 Feb 2019 16:31:02 +0100
Cornelia Huck wrote:
> On Thu, 31 Jan 2019 13:34:55 +0100
> Halil Pasic wrote:
>
> > On Thu, 31 Jan 2019 12:52:20 +0100
> > Cornelia Huck wrote:
> >
> > > On Wed, 30 Jan 2019 19:51:27 +0100
> > > Halil Pasic wrot
On Thu, 31 Jan 2019 12:52:20 +0100
Cornelia Huck wrote:
> On Wed, 30 Jan 2019 19:51:27 +0100
> Halil Pasic wrote:
>
> > On Wed, 30 Jan 2019 14:22:07 +0100
> > Cornelia Huck wrote:
> >
> > > When we get a solicited interrupt, the start function may have
On Wed, 30 Jan 2019 14:22:07 +0100
Cornelia Huck wrote:
> When we get a solicited interrupt, the start function may have
> been cleared by a csch, but we still have a channel program
> structure allocated. Make it safe to call the cp accessors in
> any case, so we can call them unconditionally.
On Wed, 30 Jan 2019 14:22:12 +0100
Cornelia Huck wrote:
> +static void fsm_async_retry(struct vfio_ccw_private *private,
> + enum vfio_ccw_event event)
> +{
> + private->cmd_region->ret_code = -EAGAIN;
> +}
> +
This is essentially dead code at the moment, isn't it? I
On Wed, 30 Jan 2019 14:22:12 +0100
Cornelia Huck wrote:
> +static void fsm_async_retry(struct vfio_ccw_private *private,
> + enum vfio_ccw_event event)
> +{
> + private->cmd_region->ret_code = -EAGAIN;
> +}
> +
This is essentially dead code at the moment, isn't it? I
On Tue, 29 Jan 2019 10:58:40 +0100
Cornelia Huck wrote:
> > > > The problem I see with the let the hardware sort it out is that, for
> > > > that to work, we need to juggle multiple translations simultaneously
> > > > (or am I wrong?). Doing that does not appear particularly simple to
> > > > me.
On Mon, 28 Jan 2019 18:13:55 +0100
Cornelia Huck wrote:
> On Fri, 25 Jan 2019 17:04:04 +0100
> Halil Pasic wrote:
>
> > Do we expect userspace/QEMU to fence the bad scenarios as tries to do
> > today, or is this supposed to change to hardware should sort out
> >
On Mon, 28 Jan 2019 18:09:48 +0100
Cornelia Huck wrote:
> On Fri, 25 Jan 2019 15:01:01 +0100
> Halil Pasic wrote:
>
> > On Fri, 25 Jan 2019 13:58:35 +0100
> > Cornelia Huck wrote:
>
> > > - The code should not be interrupted while we process the channel
>
On Fri, 25 Jan 2019 15:21:54 +0100
Cornelia Huck wrote:
> On Fri, 25 Jan 2019 15:01:01 +0100
> Halil Pasic wrote:
>
> > On Fri, 25 Jan 2019 13:58:35 +0100
> > Cornelia Huck wrote:
>
> > > - We currently do not want the user space to submit another channel
&g
On Fri, 25 Jan 2019 13:58:35 +0100
Cornelia Huck wrote:
> On Fri, 25 Jan 2019 11:24:37 +0100
> Cornelia Huck wrote:
>
> > On Thu, 24 Jan 2019 21:37:44 -0500
> > Eric Farman wrote:
> >
> > > On 01/24/2019 09:25 PM, Eric Farman wrote:
> > > >
> > > >
> > > > On 01/21/2019 06:03 AM, Cornelia
On Thu, 24 Jan 2019 21:37:44 -0500
Eric Farman wrote:
> >> @@ -188,25 +192,30 @@ static ssize_t vfio_ccw_mdev_write(struct
> >> mdev_device *mdev,
> >> {
> >> struct vfio_ccw_private *private;
> >> struct ccw_io_region *region;
> >> + int ret;
> >> if (*ppos + count > size
On Thu, 24 Jan 2019 21:25:10 -0500
Eric Farman wrote:
> > private = dev_get_drvdata(mdev_parent_dev(mdev));
> > - if (private->state != VFIO_CCW_STATE_IDLE)
> > + if (private->state == VFIO_CCW_STATE_NOT_OPER ||
> > + private->state == VFIO_CCW_STATE_STANDBY)
> > return
On Thu, 24 Jan 2019 11:19:34 +0100
Cornelia Huck wrote:
> On Thu, 24 Jan 2019 11:08:02 +0100
> Pierre Morel wrote:
>
> > On 23/01/2019 11:21, Cornelia Huck wrote:
> > > On Tue, 22 Jan 2019 19:33:46 +0100
> > > Halil Pasic wrote:
> > >
On Thu, 24 Jan 2019 11:06:37 +0100
Cornelia Huck wrote:
> On Wed, 23 Jan 2019 16:51:48 +0100
> Halil Pasic wrote:
>
> > On Mon, 21 Jan 2019 12:03:54 +0100
> > Cornelia Huck wrote:
> >
> > > Add a region to the vfio-ccw device that can be used to submit
On Mon, 21 Jan 2019 12:03:54 +0100
Cornelia Huck wrote:
> Add a region to the vfio-ccw device that can be used to submit
> asynchronous I/O instructions. ssch continues to be handled by the
> existing I/O region; the new region handles hsch and csch.
>
> Interrupt status continues to be reported
On Mon, 21 Jan 2019 12:03:52 +0100
Cornelia Huck wrote:
> Allow to extend the regions used by vfio-ccw. The first user will be
> handling of halt and clear subchannel.
>
> Signed-off-by: Cornelia Huck
Looks OK to me, but I did not look to hard. I'm likely to invest more
when v3 comes along.
R
On Wed, 23 Jan 2019 11:21:12 +0100
Cornelia Huck wrote:
> On Tue, 22 Jan 2019 19:33:46 +0100
> Halil Pasic wrote:
>
> > On Mon, 21 Jan 2019 12:03:51 +0100
> > Cornelia Huck wrote:
> >
> > > --- a/drivers/s390/cio/vfio_ccw_private.h
> > &
On Wed, 23 Jan 2019 11:34:47 +0100
Cornelia Huck wrote:
> On Tue, 22 Jan 2019 20:03:31 +0100
> Halil Pasic wrote:
>
> > On Tue, 22 Jan 2019 18:26:17 +0100
> > Cornelia Huck wrote:
> >
> > > On Tue, 22 Jan 2019 13:46:12 +0100
> > > Halil Pasic
On Mon, 21 Jan 2019 12:03:51 +0100
Cornelia Huck wrote:
> --- a/drivers/s390/cio/vfio_ccw_private.h
> +++ b/drivers/s390/cio/vfio_ccw_private.h
> @@ -28,6 +28,7 @@
> * @mdev: pointer to the mediated device
> * @nb: notifier for vfio events
> * @io_region: MMIO region to input/output I/O arg
On Mon, 21 Jan 2019 12:03:53 +0100
Cornelia Huck wrote:
> The vfio-ccw code will need this, and it matches treatment of ssch
> and csch.
>
> Reviewed-by: Pierre Morel
> Signed-off-by: Cornelia Huck
Reviewed-by: Halil Pasic
;)
> ---
> drivers/s390/cio/ioasm.c | 1 +
On Tue, 22 Jan 2019 18:26:17 +0100
Cornelia Huck wrote:
> On Tue, 22 Jan 2019 13:46:12 +0100
> Halil Pasic wrote:
>
> > On Tue, 22 Jan 2019 12:53:22 +0100
> > Cornelia Huck wrote:
> >
> > > On Tue, 22 Jan 2019 12:17:37 +0100
> > > Halil Pasic w
On Tue, 22 Jan 2019 12:53:22 +0100
Cornelia Huck wrote:
> On Tue, 22 Jan 2019 12:17:37 +0100
> Halil Pasic wrote:
>
> > On Tue, 22 Jan 2019 11:29:26 +0100
> > Cornelia Huck wrote:
> >
> > > On Mon, 21 Jan 2019 21:20:18 +0100
> > > Halil Pasic w
On Mon, 21 Jan 2019 12:03:50 +0100
Cornelia Huck wrote:
> When we get a solicited interrupt, the start function may have
> been cleared by a csch, but we still have a channel program
> structure allocated. Make it safe to call the cp accessors in
> any case, so we can call them unconditionally.
>
On Tue, 22 Jan 2019 11:29:26 +0100
Cornelia Huck wrote:
> On Mon, 21 Jan 2019 21:20:18 +0100
> Halil Pasic wrote:
>
> > On Mon, 21 Jan 2019 12:03:51 +0100
> > Cornelia Huck wrote:
> >
> > > Rework handling of multiple I/O requests to return -EAGAIN if
&g
On Mon, 21 Jan 2019 12:03:51 +0100
Cornelia Huck wrote:
> Rework handling of multiple I/O requests to return -EAGAIN if
> we are already processing an I/O request. Introduce a mutex
> to disallow concurrent writes to the I/O region.
>
> The expectation is that userspace simply retries the operat
On Wed, 16 Jan 2019 17:41:30 +0100
Cornelia Huck wrote:
> On Wed, 16 Jan 2019 16:44:09 +0100
> Pierre Morel wrote:
>
> > On 16/01/2019 15:50, Halil Pasic wrote:
>
> > > @Connie, will you add the Fixes tag? Do we need a cc stable (since
> > > broken since 2
On Wed, 16 Jan 2019 15:16:44 +0100
Pierre Morel wrote:
> On 16/01/2019 13:40, Halil Pasic wrote:
> > On Tue, 15 Jan 2019 10:35:42 -0500
> > Collin Walling wrote:
> >
> >> On 1/10/19 8:00 AM, Pierre Morel wrote:
> >>> The size of the accessible iommu me
On Tue, 15 Jan 2019 10:35:42 -0500
Collin Walling wrote:
> On 1/10/19 8:00 AM, Pierre Morel wrote:
> > The size of the accessible iommu memory region in the guest
> > is given to the IOMMU by the guest through the mpcifc request
> > specifying the PCI Base Address and the PCI Address Limit.
> >
Cc: Eduardo Habkost
> Signed-off-by: Michael Roth
> Signed-off-by: Greg Kurz
> Reviewed-by: David Gibson
Acked-by: Halil Pasic
On Thu, 10 Jan 2019 17:57:22 +0100
Cornelia Huck wrote:
> > I thought the same. They could also be made unsigned long or
> > unsigned long long to increase the number of child devices that can be
> > plugged in before having to deal with exceeding the index value.
>
> Making them unsigned long
On Thu, 10 Jan 2019 10:50:30 -0500
Tony Krowiak wrote:
> On 1/9/19 12:35 PM, Halil Pasic wrote:
> > On Wed, 9 Jan 2019 10:36:11 -0500
> > Tony Krowiak wrote:
> >
> >> On 1/9/19 5:14 AM, Cornelia Huck wrote:
[..]
> >> A search reveals that max_index
On Wed, 9 Jan 2019 10:36:11 -0500
Tony Krowiak wrote:
> On 1/9/19 5:14 AM, Cornelia Huck wrote:
> > On Tue, 8 Jan 2019 15:34:37 -0500
> > Tony Krowiak wrote:
> >
> >> On 1/8/19 12:06 PM, Cornelia Huck wrote:
> >>> On Tue, 8 Jan 2019 17:50:21 +0100
>
On Wed, 9 Jan 2019 17:37:49 +0100
David Hildenbrand wrote:
> On 09.01.19 17:27, Tony Krowiak wrote:
> > On 1/9/19 6:30 AM, Cornelia Huck wrote:
> >> On Tue, 8 Jan 2019 23:13:39 +0100
> >> David Hildenbrand wrote:
> >>
> >>> On 08.01.19 20:52, Tony Krowiak wrote:
> On 1/8/19 11:09 AM, David
#x27; option is not
> specified on the QEMU command line.
>
> Signed-off-by: Tony Krowiak
> Reviewed-by: Pierre Morel
> Tested-by: Pierre Morel
Reviewed-by: Halil Pasic
On Tue, 8 Jan 2019 11:37:56 -0500
"Jason J. Herne" wrote:
> On 12/12/18 9:34 AM, Cornelia Huck wrote:
> ...
> >>
> >> NOTE: It has been a while, but I've finally chased down my infamous "reset
> >> bug".
> >> On subsystem reset (I see this right after host ipl) we sometimes end up
> >> getting
To resolve the problem, a new 'num_children' field is being added to the
> > > BusState structure to keep track of the number of children plugged into
> > > the
> > > bus. It will be incremented when a child is plugged, and decremented when
> > > a
> > &g
adds a default branch for device plug and unplug.
>
> Spotted by Coverity: CID 1398593
>
> Signed-off-by: Li Qiang
Reviewed-by: Halil Pasic
[..]
On Fri, 4 Jan 2019 15:10:05 +0100
Cornelia Huck wrote:
> On Thu, 3 Jan 2019 07:16:12 -0800
> Li Qiang wrote:
>
> > When getting the 'pbdev', the if...else has no default branch.
> > From Coverity, the 'pbdev' maybe null when the 'dev' is not
> > the TYPE_PCI_BRIDGE/TYPE_PCI_DEVICE/TYPE_S390_PC
On Thu, 3 Jan 2019 15:54:38 +0100
Cornelia Huck wrote:
> On Thu, 3 Jan 2019 06:02:46 -0800
> Li Qiang wrote:
>
> > When getting the 'pbdev', the if...else has no default branch.
> > From Coverity, the 'pbdev' maybe null when the 'dev' is not
> > the TYPE_PCI_BRIDGE/TYPE_PCI_DEVICE/TYPE_S390_PC
On Fri, 21 Dec 2018 12:23:32 +0100
Cornelia Huck wrote:
[..]
>
> You've really lost me here :( I fear you're criticizing something I
> don't want to implement; I'll write some code, that should make things
> much easier to discuss.
>
Nod.
> TBH, I have no idea how this will scale to many vfio
On Wed, 19 Dec 2018 12:54:42 +0100
Cornelia Huck wrote:
> On Fri, 7 Dec 2018 17:54:23 +0100
> Halil Pasic wrote:
>
> > On Fri, 7 Dec 2018 11:05:29 +0100
> > Cornelia Huck wrote:
> >
> > > > > I think most of the sorting-out-the-operations stuff shoul
201 - 300 of 1027 matches
Mail list logo
