On Wed, 3 Jul 2024 13:00:21 +0200 (CEST)
BALATON Zoltan wrote:
> On Wed, 3 Jul 2024, Michael S. Tsirkin wrote:
> > On Wed, Jul 03, 2024 at 04:15:23AM +0200, BALATON Zoltan wrote:
> >> On Tue, 2 Jul 2024, Michael S. Tsirkin wrote:
> >>> On Thu, Jun 27, 2024 at 03:08:00PM +0900, Akihiko Odaki w
Nothing good can happen when we overlap capabilities. This may happen
> when plugging in assigned devices or when devices models contain bugs.
> Detect the overlap and report it.
>
> Based on qemu-kvm commit by Alex Williamson.
>
> Signed-off-by: Jan Kiszka
&g
On Thu, 27 Oct 2022 05:15:25 +0900
Akihiko Odaki wrote:
> The code generating errors in pci_add_capability has a comment which
> says:
> > Verify that capabilities don't overlap. Note: device assignment
> > depends on this check to verify that the device is not broken.
> > Should never trigger f
On Thu, 27 Oct 2022 15:36:49 +0900
Akihiko Odaki wrote:
> vfio_add_std_cap() is designed to ensure that capabilities do not
> overlap, but it failed to do so for MSI and MSI-X capabilities.
>
> Ensure MSI and MSI-X capabilities do not overlap with others by omitting
> other overlapping capabilit
On Fri, 28 Oct 2022 21:26:13 +0900
Akihiko Odaki wrote:
> vfio_add_std_cap() is designed to ensure that capabilities do not
> overlap, but it failed to do so for MSI and MSI-X capabilities.
>
> Ensure MSI and MSI-X capabilities do not overlap with others by omitting
> other overlapping capabilit
On Sat, 29 Oct 2022 01:12:11 +0900
Akihiko Odaki wrote:
> On 2022/10/28 23:16, Alex Williamson wrote:
> > On Fri, 28 Oct 2022 21:26:13 +0900
> > Akihiko Odaki wrote:
> >
> >> vfio_add_std_cap() is designed to ensure that capabilities do not
> >> over
On Mon, 31 Oct 2022 21:33:03 +0900
Akihiko Odaki wrote:
> pci_add_capability() checks whether capabilities overlap, and notifies
> its caller so that it can properly handle the case. However, in the
> most cases, the capabilities actually never overlap, and the interface
> incurred extra error ha
On Tue, 19 Apr 2016 12:13:29 +0300
"Michael S. Tsirkin" wrote:
> On Mon, Apr 18, 2016 at 02:29:33PM -0400, David Woodhouse wrote:
> > On Mon, 2016-04-18 at 19:27 +0300, Michael S. Tsirkin wrote:
> > > I balk at adding more hacks to a broken system. My goals are
> > > merely to
> > > - make thin
On Thu, 13 Sep 2018 12:04:34 +0200
Paolo Bonzini wrote:
> On 13/09/2018 11:11, Paolo Bonzini wrote:
> > On 13/09/2018 08:03, Fam Zheng wrote:
> >> On Wed, 09/12 14:42, Paolo Bonzini wrote:
> >>> On 12/09/2018 13:50, Fam Zheng wrote:
> > I think it's okay if it is invoked. The sequence
On Wed, 10 Jan 2018 17:18:39 +0800
Fam Zheng wrote:
> This is a library to manage the host vfio interface, which could be used
> to implement userspace device driver code in QEMU such as NVMe or net
> controllers.
>
> Signed-off-by: Fam Zheng
> ---
> include/qemu/vfio-helpers.h | 30 ++
> uti
On Fri, 14 Feb 2020 10:19:50 +0100
Michal Privoznik wrote:
> On 2/14/20 9:47 AM, Michal Privoznik wrote:
> > In a few places we report errno formatted as a negative integer.
> > This is not as user friendly as it can be. Use strerror() and/or
> > error_setg_errno() instead.
> >
> > Signed-off-by
On Mon, 19 Oct 2020 13:32:17 +
Zhengui li wrote:
> fix incorrect print type.
Why is it incorrect, describe your change. Patches must include a
Signed-off-by to adhere to the developer's certificate of origin.
Thanks,
Alex
> ---
> hw/vfio/common.c | 4 ++--
> 1 file changed, 2 insertions(
On Tue, 11 Aug 2020 19:28:44 +0200
Philippe Mathieu-Daudé wrote:
> Add a trace event to display the amount of IRQs available
> on the device.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> util/vfio-helpers.c | 1 +
> util/trace-events | 1 +
> 2 files changed, 2 insertions(+)
>
> diff -
On Tue, 11 Aug 2020 19:28:45 +0200
Philippe Mathieu-Daudé wrote:
> Add a new 'index' argument to qemu_vfio_pci_init_irq() to be able
> to initialize other IRQs than IRQ #0. Adapt the single user of this
> API in nvme_init().
This is actually addressing the what the vfio uAPI refers to as the
sub
On Thu, 13 Aug 2020 19:29:52 +0200
Philippe Mathieu-Daudé wrote:
> Once opened, we will used the same IRQ type for all our event
> notifiers, so pass the argument when we open the PCI device,
> store the IRQ type in the driver state, and directly use the
> value saved in the state each time we ca
On Thu, 13 Aug 2020 19:29:54 +0200
Philippe Mathieu-Daudé wrote:
> As we want to use more than one single IRQ, add a check that
> the device accept our request to use multiple IRQs.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> util/vfio-helpers.c | 6 ++
> util/trace-events | 1 +
>
On Thu, 13 Aug 2020 19:29:56 +0200
Philippe Mathieu-Daudé wrote:
> Let qemu_vfio_pci_init_irq() take an 'index' argument, so we can
> set the EventNotifier to a specific IRQ.
> Add a safety check. Since our helper is limited to one single IRQ
> we are safe.
>
> Our only user is the NVMe block dr
On Thu, 13 Aug 2020 19:29:57 +0200
Philippe Mathieu-Daudé wrote:
> Now that our helper is ready for handling multiple IRQs, let
> qemu_vfio_open_pci() take an 'irq_count' argument.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
As with patch 2/ tying IRQ setup with the opening of a device see
On Tue, 18 Aug 2020 18:45:06 +0200
Philippe Mathieu-Daudé wrote:
> The vfio-helpers implementation expects a TYPEv1 IOMMU, see
> qemu_vfio_init_pci:
>
> 263 if (!ioctl(s->container, VFIO_CHECK_EXTENSION, VFIO_TYPE1_IOMMU)) {
> 264 error_setg_errno(errp, errno, "VFIO IOMMU check f
On Tue, 18 Aug 2020 18:45:08 +0200
Philippe Mathieu-Daudé wrote:
> qemu_vfio_pci_init_irq() allows us to initialize any type of IRQ,
> but only one. Introduce qemu_vfio_pci_init_msix_irqs() which is
> specific to MSIX IRQ type, and allow us to use multiple IRQs
> (thus passing multiple eventfd no
On Wed, 19 Aug 2020 18:03:17 +0200
Philippe Mathieu-Daudé wrote:
> qemu_vfio_pci_init_irq() allows us to initialize any type of IRQ,
> but only one. Introduce qemu_vfio_pci_init_msix_irqs() which is
> specific to MSIX IRQ type, and allow us to use multiple IRQs
> (thus passing multiple eventfd no
On Thu, 10 Sep 2020 17:29:25 +0200
Philippe Mathieu-Daudé wrote:
> Hi Stefan, Alex.
>
> On 9/10/20 12:44 PM, Stefan Hajnoczi wrote:
> > On Wed, Sep 09, 2020 at 04:23:53PM +0200, Philippe Mathieu-Daudé wrote:
> >> +/**
> >> + * Initialize device MSIX IRQs and register event notifiers.
> >> + *
On Mon, 14 Sep 2020 11:37:03 +0100
Stefan Hajnoczi wrote:
> On Wed, Sep 09, 2020 at 02:51:50PM +0200, Philippe Mathieu-Daudé wrote:
> > On 9/7/20 1:16 PM, Stefan Hajnoczi wrote:
> > > Development of the userspace NVMe block driver picked up again recently.
> > > After talking with Fam I am step
On Wed, 2 Mar 2022 12:36:43 +0100
Sergio Lopez wrote:
> event_notifier_get_fd(const EventNotifier *e) always returns
> EventNotifier's read file descriptor (rfd). This is not a problem when
> the EventNotifier is backed by a an eventfd, as a single file
> descriptor is used both for reading and
On Wed, 2 Mar 2022 16:23:42 +0100
Sergio Lopez wrote:
> On Wed, Mar 02, 2022 at 08:12:34AM -0700, Alex Williamson wrote:
> > On Wed, 2 Mar 2022 12:36:43 +0100
> > Sergio Lopez wrote:
> >
> > > event_notifier_get_fd(const EventNotifier *e) always returns
&
On Thu, 3 Nov 2022 18:16:10 +0200
Avihai Horon wrote:
> Currently, if IOMMU of a VFIO container doesn't support dirty page
> tracking, migration is blocked. This is because a DMA-able VFIO device
> can dirty RAM pages without updating QEMU about it, thus breaking the
> migration.
>
> However, th
On Thu, 3 Nov 2022 18:16:13 +0200
Avihai Horon wrote:
> Move vfio_dev_get_region_info() logic from vfio_migration_probe() to
> vfio_migration_init(). This logic is specific to v1 protocol and moving
> it will make it easier to add the v2 protocol implementation later.
> No functional changes inte
On Thu, 3 Nov 2022 18:16:15 +0200
Avihai Horon wrote:
> Add implementation of VFIO migration protocol v2. The two protocols, v1
> and v2, will co-exist and in next patch v1 protocol will be removed.
>
> There are several main differences between v1 and v2 protocols:
> - VFIO device state is now
On Thu, 3 Nov 2022 18:16:17 +0200
Avihai Horon wrote:
> If vfio_migration_set_state() fails to set the device in the requested
> state it tries to put it in a recover state. If setting the device in
> the recover state fails as well, hw_error is triggered and the VM is
> aborted.
>
> To improve
On Thu, 17 Nov 2022 19:07:10 +0200
Avihai Horon wrote:
> On 16/11/2022 20:29, Alex Williamson wrote:
> > On Thu, 3 Nov 2022 18:16:15 +0200
> > Avihai Horon wrote:
> >> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> >> index e784374453..62afc23a8c 1006
On Thu, 17 Nov 2022 19:11:47 +0200
Avihai Horon wrote:
> On 16/11/2022 20:36, Alex Williamson wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Thu, 3 Nov 2022 18:16:17 +0200
> > Avihai Horon wrote:
> >
> >>
On Thu, 24 Nov 2022 14:41:00 +0200
Avihai Horon wrote:
> On 20/11/2022 11:34, Avihai Horon wrote:
> >
> > On 17/11/2022 19:38, Alex Williamson wrote:
> >> External email: Use caution opening links or attachments
> >>
> >>
> >> On Thu,
On Mon, 28 Nov 2022 15:40:23 -0400
Jason Gunthorpe wrote:
> On Mon, Nov 28, 2022 at 11:50:03AM -0700, Alex Williamson wrote:
>
> > There's a claim here about added complexity that I'm not really seeing.
> > It looks like we simply make an ioctl call here and scale
On Mon, 28 Nov 2022 16:56:39 -0400
Jason Gunthorpe wrote:
> On Mon, Nov 28, 2022 at 01:36:30PM -0700, Alex Williamson wrote:
> > On Mon, 28 Nov 2022 15:40:23 -0400
> > Jason Gunthorpe wrote:
> >
> > > On Mon, Nov 28, 2022 at 11:50:03AM -0700, Alex Williamson wro
On Thu, 29 Dec 2022 13:03:34 +0200
Avihai Horon wrote:
> From: Juan Quintela
IMHO, there should always be a commit log description. Why is this a
simplification? What does it allow us to do? Nothing later obviously
depends on this, why is it part of this series? Thanks,
Alex
> Signed-off-
On Tue, 3 Jan 2023 11:13:21 +
"Dr. David Alan Gilbert" wrote:
> * Avihai Horon (avih...@nvidia.com) wrote:
> > As part of its error flow, vfio_vmstate_change() accesses
> > MigrationState->to_dst_file without any checks. This can cause a NULL
> > pointer dereference if the error flow is taken
On Thu, 29 Dec 2022 13:03:36 +0200
Avihai Horon wrote:
> Currently, if IOMMU of a VFIO container doesn't support dirty page
> tracking, migration is blocked. This is because a DMA-able VFIO device
> can dirty RAM pages without updating QEMU about it, thus breaking the
> migration.
>
> However, t
On Thu, 29 Dec 2022 13:03:31 +0200
Avihai Horon wrote:
> Hello,
>
> Now that QEMU 8.0 development cycle has started and MIG_DATA_SIZE ioctl
> is in kernel v6.2-rc1, I am sending v5 of this series with linux headers
> update and with the preview patches in v4 merged into this series.
>
>
>
> F
On Mon, 16 Jan 2023 16:11:26 +0200
Avihai Horon wrote:
> Currently, if IOMMU of a VFIO container doesn't support dirty page
> tracking, migration is blocked. This is because a DMA-able VFIO device
> can dirty RAM pages without updating QEMU about it, thus breaking the
> migration.
>
> However, t
On Mon, 16 Jan 2023 16:11:27 +0200
Avihai Horon wrote:
> Add new function qemu_file_get_to_fd() that allows reading data from
> QEMUFile and writing it straight into a given fd.
>
> This will be used later in VFIO migration code.
>
> Signed-off-by: Avihai Horon
> Reviewed-by: Vladimir Sementso
On Mon, 16 Jan 2023 16:11:31 +0200
Avihai Horon wrote:
> Implement the basic mandatory part of VFIO migration protocol v2.
> This includes all functionality that is necessary to support
> VFIO_MIGRATION_STOP_COPY part of the v2 protocol.
>
> The two protocols, v1 and v2, will co-exist and in the
On Sun, 22 Jan 2023 12:31:33 +0200
Avihai Horon wrote:
> On 21/01/2023 1:07, Alex Williamson wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Mon, 16 Jan 2023 16:11:31 +0200
> > Avihai Horon wrote:
> >
> >> Impl
On Mon, 6 Feb 2023 14:31:30 +0200
Avihai Horon wrote:
> Currently VFIO migration doesn't implement some kind of intermediate
> quiescent state in which P2P DMAs are quiesced before stopping or
> running the device. This can cause problems in multi-device migration
> where the devices are doing P2
On Mon, 6 Feb 2023 14:31:33 +0200
Avihai Horon wrote:
> @@ -523,6 +745,41 @@ static int vfio_save_iterate(QEMUFile *f, void *opaque)
> return 0;
> }
>
> +static int vfio_save_complete_precopy(QEMUFile *f, void *opaque)
> +{
> +VFIODevice *vbasedev = opaque;
> +enum vfio_device_mig_
On Mon, 6 Feb 2023 14:31:37 +0200
Avihai Horon wrote:
> Now that VFIO migration protocol v2 has been implemented and v1 protocol
> has been removed, update the documentation according to v2 protocol.
>
> Signed-off-by: Avihai Horon
> Reviewed-by: Cédric Le Goater
> ---
> docs/devel/vfio-migra
On Wed, 8 Feb 2023 15:08:15 +0200
Avihai Horon wrote:
> On 08/02/2023 0:34, Alex Williamson wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Mon, 6 Feb 2023 14:31:30 +0200
> > Avihai Horon wrote:
> >
> >> Curr
cious-lang/conscious-lang-docs/blob/main/faq.md
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/vfio/pci.h| 2 +-
> hw/vfio/pci-quirks.c | 14 +++---
> hw/vfio/pci.c| 4 ++--
> hw/vfio/trace-events | 2 +-
> 4 files changed, 11 insertions
cious-lang/conscious-lang-docs/blob/main/faq.md
>
> Reviewed-by: Alex Williamson
> Acked-by: Alex Williamson
> Reviewed-by: Daniel P. Berrangé
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/vfio/pci.h| 2 +-
> hw/vfio/pci-quirks.c | 14 +++---
>
On Wed, 10 Apr 2024 18:06:03 +0200
Philippe Mathieu-Daudé wrote:
> sprintf() is deprecated on Darwin since macOS 13.0 / XCode 14.1,
> resulting in painful developper experience. Use g_strdup_printf()
> instead.
Isn't this code only compiled for Linux hosts? Maybe still a valid
change, but the r
On Thu, 10 Apr 2025 09:07:51 -0700
Farhan Ali wrote:
> On 4/3/2025 2:24 PM, Alex Williamson wrote:
> > On Thu, 3 Apr 2025 13:33:17 -0700
> > Farhan Ali wrote:
> >
> >> On 4/3/2025 11:05 AM, Alex Williamson wrote:
> >>> On Thu, 3 Apr 2
On Thu, 3 Apr 2025 11:44:42 -0400
Stefan Hajnoczi wrote:
> On Thu, Apr 03, 2025 at 09:47:26AM +0200, Niklas Schnelle wrote:
> > On Wed, 2025-04-02 at 11:51 -0400, Stefan Hajnoczi wrote:
> > > On Tue, Apr 01, 2025 at 10:22:43AM -0700, Farhan Ali wrote:
> > > > Hi,
> > > >
> > > > Recently on
On Thu, 3 Apr 2025 13:33:17 -0700
Farhan Ali wrote:
> On 4/3/2025 11:05 AM, Alex Williamson wrote:
> > On Thu, 3 Apr 2025 10:33:52 -0700
> > Farhan Ali wrote:
> >
> >> On 4/3/2025 9:27 AM, Alex Williamson wrote:
> >>> On Thu, 3 Apr 2025 1
On Thu, 3 Apr 2025 10:33:52 -0700
Farhan Ali wrote:
> On 4/3/2025 9:27 AM, Alex Williamson wrote:
> > On Thu, 3 Apr 2025 11:44:42 -0400
> > Stefan Hajnoczi wrote:
> >
> >> On Thu, Apr 03, 2025 at 09:47:26AM +0200, Niklas Schnelle wrote:
> >>>
53 matches
Mail list logo
