From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fIJ7k-0006Rv-V8 for qemu-devel@nongnu.org; Mon, 14 May 2018 15:27:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fIJ7h-0008FZ-N0 for qemu-devel@nongnu.org; Mon, 14 May 2018 15:27:08 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:33008 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fIJ7h-0008Ej-GQ for qemu-devel@nongnu.org; Mon, 14 May 2018 15:27:05 -0400 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4EJNkNF009690 for ; Mon, 14 May 2018 15:27:04 -0400 Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by mx0a-001b2d01.pphosted.com with ESMTP id 2hyg9p8rnf-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 14 May 2018 15:27:04 -0400 Received: from localhost by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 14 May 2018 13:27:03 -0600 References: <1525782303-16940-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1525782303-16940-5-git-send-email-akrowiak@linux.vnet.ibm.com> <1806faa3-dc46-f638-5c87-8a7415c9025a@linux.vnet.ibm.com> <369a35de-4313-ee41-bb11-634c6bc45a72@linux.ibm.com> From: Tony Krowiak Date: Mon, 14 May 2018 15:26:53 -0400 MIME-Version: 1.0 In-Reply-To: <369a35de-4313-ee41-bb11-634c6bc45a72@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Message-Id: <3531be60-c468-290c-135f-2c1091bc5d80@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v5 4/6] s390x/vfio: ap: Introduce VFIO AP device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: pmorel@linux.ibm.com, Halil Pasic , qemu-devel@nongnu.org Cc: qemu-s390x@nongnu.org, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, borntraeger@de.ibm.com, cohuck@redhat.com, david@redhat.com, bjsdjshi@linux.vnet.ibm.com, pmorel@linux.vnet.ibm.com, alifm@linux.vnet.ibm.com, mjrosato@linux.vnet.ibm.com, jjherne@linux.vnet.ibm.com, pasic@linux.vnet.ibm.com, eskultet@redhat.com, berrange@redhat.com, alex.williamson@redhat.com, eric.auger@redhat.com, pbonzini@redhat.com, peter.maydell@linaro.org, agraf@suse.de, rth@twiddle.net On 05/11/2018 05:02 AM, Pierre Morel wrote: > On 10/05/2018 15:10, Tony Krowiak wrote: >> On 05/09/2018 10:28 AM, Halil Pasic wrote: >>> >>> >>> On 05/08/2018 02:25 PM, Tony Krowiak wrote: >>>> Introduces a VFIO based AP device. The device is defined via >>>> the QEMU command line by specifying: >>>> >>>> -device vfio-ap,sysfsdev= >>>> >>>> There may be only one vfio-ap device configured for a guest. >>>> >>>> The mediated matrix device is created by the VFIO AP device >>> [..] >>>> + * directory. >>>> + */ >>>> + >>>> +#include >>>> +#include >>>> +#include "qemu/osdep.h" >>>> +#include "qapi/error.h" >>>> +#include "hw/sysbus.h" >>>> +#include "hw/vfio/vfio.h" >>>> +#include "hw/vfio/vfio-common.h" >>>> +#include "hw/s390x/ap-device.h" >>>> +#include "qemu/error-report.h" >>>> +#include "qemu/queue.h" >>>> +#include "qemu/option.h" >>>> +#include "qemu/config-file.h" >>>> +#include "cpu.h" >>>> +#include "kvm_s390x.h" >>>> +#include "sysemu/sysemu.h" >>>> + >>>> +#define VFIO_AP_DEVICE_TYPE "vfio-ap" >>>> + >>>> +typedef struct VFIOAPDevice { >>>> + APDevice apdev; >>>> + VFIODevice vdev; >>>> + QTAILQ_ENTRY(VFIOAPDevice) sibling; >>>> +} VFIOAPDevice; >>>> + >>>> +VFIOAPDevice *vfio_apdev; >>>> + >>>> +static void vfio_ap_compute_needs_reset(VFIODevice *vdev) >>>> +{ >>>> + vdev->needs_reset = false; >>>> +} >>>> + >>>> +/* >>>> + * We don't need vfio_hot_reset_multi and vfio_eoi operations for >>>> + * vfio-ap-matrix device now. >>>> + */ >>>> +struct VFIODeviceOps vfio_ap_ops = { >>>> + .vfio_compute_needs_reset = vfio_ap_compute_needs_reset, >>>> +}; >>>> + >>> >>> I'm not familiar with the vfio infrastructure, but AFAIR I >>> haven't seen any substantial reset handling (QEMU or kernel). >>> Did I miss something? >> >> No, you didn't miss anything, there is no reset handling. >> >>> >>> If I did not. I think this is a big problem. We need to at least >>> zeroize the queues (e.g. on system reset) to avoid leaking >>> sensitive information. Without this, there is no sane way to use >>> ap-passthrough. Or am I wrong? >> >> I do not have a definitive answer, I will have to look into it. >> I'm thinking that since we are using ap-passthrough, the AP bus >> running on the guest would be responsible for handling reset possibly >> by resetting or zeroizing its queues. I'll get back to you on this. >> >>> >>> Regards, >>> Halil >>> >> > On the host, on system reset or subsystem reset, the queues are zeroized. Can you point me to where this is done? > > > It means we must do the same for the guest and implement both cold and > hot reset. > > One of the patches in the interrupt handling serie I sent last > wednesday zeroize > the queues on starting and stopping the guest so no data leak occurs > between > host and guests or between guests. I'm sorry, I was not aware of them and consequently have not yet reviewed them. I'll take a look at them ASAP. > > > However we should follow the machine specification and zeroize the > queues between > two guest reset too. i.e. in the "reset" call back. and implement the > VFIO_DEVICE_RESET > ioctl. Can you point me to the specification to which you are referring? You can send a personal email if this is restricted information. > > > > Regards, > > Pierre >