* CFP WEBIST 2019 - 15th Int.l Conf. on Web Information Systems and Technologies (Vienna/Austria)
From: webist @ 2019-02-21 12:18 UTC (permalink / raw)
To: virtualization
SUBMISSION DEADLINE
15th International Conference on Web Information Systems and Technologies
Submission Deadline: April 29, 2019
http://www.webist.org/
September 18 - 20, 2019
Vienna, Austria.
WEBIST is organized in 5 major tracks:
- Internet Technology
- Mobile and NLP Information Systems
- Service Based Information Systems, Platforms and Eco-Systems
- Web Intelligence
- Web Interfaces
Proceedings will be submitted for indexation by: DBLP, Thomson Reuters, EI, SCOPUS, Semantic Scholar and Google Scholar.
With the presence of internationally distinguished keynote speakers:
Steffen Staab, University of Koblenz-Landau, Germany
Karl Aberer, EPFL, Switzerland
A short list of presented papers will be selected so that revised and extended versions of these papers will be published by Springer.
All papers presented at the congress venue will also be available at the SCITEPRESS Digital Library (http://www.scitepress.org/DigitalLibrary/).
Should you have any question please don't hesitate contacting me.
Kind regards,
WEBIST Secretariat
Address: Avenida de São Francisco Xavier Lote 7L Cave
2910-595 Setubal, Portugal
Tel: +351 265 520 184
Fax: +351 265 520 186
Web: http://www.webist.org/
e-mail: webist.secretariat@insticc.org
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* CFP PECCS 2019 - 9th Int.l Conf. on Pervasive and Embedded Computing and Communication Systems (Vienna/Austria)
From: peccs @ 2019-02-21 12:18 UTC (permalink / raw)
To: virtualization
SUBMISSION DEADLINE
9th International Conference on Pervasive and Embedded Computing and Communication Systems
Submission Deadline: April 29, 2019
http://www.peccs.org/
September 19 - 20, 2019
Vienna, Austria.
PECCS is organized in 5 major tracks:
- Wireless and Mobile Technologies
- Sensor Networks: Software, Architectures and Applications
- Intelligent Data Analysis and Processing
- Mobile Computing Systems and Services
- Multimedia Signal Processing
Proceedings will be submitted for indexation by: DBLP, Thomson Reuters, EI, SCOPUS, Semantic Scholar and Google Scholar.
With the presence of internationally distinguished keynote speakers:
Andreas Holzinger, Medical University Graz, Austria
Kayyali Mohamed, International Federation of Global & Green Information Communucation Technology, United States
A short list of presented papers will be selected so that revised and extended versions of these papers will be published by Springer.
All papers presented at the congress venue will also be available at the SCITEPRESS Digital Library (http://www.scitepress.org/DigitalLibrary/).
Should you have any question please don't hesitate contacting me.
Kind regards,
PECCS Secretariat
Address: Avenida de São Francisco Xavier Lote 7L Cave
2910-595 Setubal, Portugal
Tel: +351 265 520 185
Fax: +351 265 520 186
Web: http://www.peccs.org/
e-mail: peccs.secretariat@insticc.org
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v2 2/2] drm/qxl: kick out vgacon
From: Daniel Vetter @ 2019-02-21 12:20 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: David Airlie, open list, dri-devel,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, daniel,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, Dave Airlie
In-Reply-To: <20190221113534.20764-3-kraxel@redhat.com>
On Thu, Feb 21, 2019 at 12:35:34PM +0100, Gerd Hoffmann wrote:
> Problem: qxl switches from native mode back into vga compatibility mode
> when it notices someone is accessing vga registers. And vgacon does
> exactly that before fbcon takes over. So make sure we kick out vgacon
> early enough that it wouldn't disturb us.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> drivers/gpu/drm/qxl/qxl_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index bb81e310eb..08446561aa 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -95,6 +95,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> goto modeset_cleanup;
>
> drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
> + drm_fb_helper_kick_out_vgacon();
I was thinking of checking whether pdev is a VGA class device and whether
it decodes vga access, and in that case automatically calling
kick_out_vgacon from remove_conflicting_pci_framebuffer. Since that's what
drivers want anyway, and those who don't can open code it.
Or is there an issue with that?
-Daniel
> drm_fbdev_generic_setup(&qdev->ddev, 32);
> return 0;
>
> --
> 2.9.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH v2 2/2] drm/qxl: kick out vgacon
From: Gerd Hoffmann @ 2019-02-21 13:06 UTC (permalink / raw)
To: dri-devel, Dave Airlie, David Airlie,
open list:DRM DRIVER FOR QXL VIRTUAL GPU,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, open list
In-Reply-To: <20190221122011.GP2665@phenom.ffwll.local>
On Thu, Feb 21, 2019 at 01:20:11PM +0100, Daniel Vetter wrote:
> On Thu, Feb 21, 2019 at 12:35:34PM +0100, Gerd Hoffmann wrote:
> > Problem: qxl switches from native mode back into vga compatibility mode
> > when it notices someone is accessing vga registers. And vgacon does
> > exactly that before fbcon takes over. So make sure we kick out vgacon
> > early enough that it wouldn't disturb us.
> >
> > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> > ---
> > drivers/gpu/drm/qxl/qxl_drv.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> > index bb81e310eb..08446561aa 100644
> > --- a/drivers/gpu/drm/qxl/qxl_drv.c
> > +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> > @@ -95,6 +95,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> > goto modeset_cleanup;
> >
> > drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
> > + drm_fb_helper_kick_out_vgacon();
>
> I was thinking of checking whether pdev is a VGA class device and whether
> it decodes vga access, and in that case automatically calling
> kick_out_vgacon from remove_conflicting_pci_framebuffer. Since that's what
> drivers want anyway, and those who don't can open code it.
>
> Or is there an issue with that?
It'll need more careful testing to make sure we don't have unwanted side
effects when just doing it for everyone. And I guess most drivers don't
care much because their hardware ignores vga port writes once they are
switched out of vga text mode.
Dunno why i915 needs this.
In case of qxl it is more a historical leftover. The very first qxl
device revision had no explicit qxl command to switch from qxl native
mode back to vga compatibility mode, vga port access was used for that
instead. It's long fixed, but the qxl device still has that quirk for
compatibility with very old guest drivers.
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH v2 2/2] drm/qxl: kick out vgacon
From: Daniel Vetter @ 2019-02-21 14:24 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: David Airlie, open list, dri-devel,
open list:DRM DRIVER FOR QXL VIRTUAL GPU,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, Dave Airlie
In-Reply-To: <20190221130623.rjtmtoe2qf7dgy2t@sirius.home.kraxel.org>
On Thu, Feb 21, 2019 at 02:06:23PM +0100, Gerd Hoffmann wrote:
> On Thu, Feb 21, 2019 at 01:20:11PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 21, 2019 at 12:35:34PM +0100, Gerd Hoffmann wrote:
> > > Problem: qxl switches from native mode back into vga compatibility mode
> > > when it notices someone is accessing vga registers. And vgacon does
> > > exactly that before fbcon takes over. So make sure we kick out vgacon
> > > early enough that it wouldn't disturb us.
> > >
> > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> > > ---
> > > drivers/gpu/drm/qxl/qxl_drv.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> > > index bb81e310eb..08446561aa 100644
> > > --- a/drivers/gpu/drm/qxl/qxl_drv.c
> > > +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> > > @@ -95,6 +95,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> > > goto modeset_cleanup;
> > >
> > > drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
> > > + drm_fb_helper_kick_out_vgacon();
> >
> > I was thinking of checking whether pdev is a VGA class device and whether
> > it decodes vga access, and in that case automatically calling
> > kick_out_vgacon from remove_conflicting_pci_framebuffer. Since that's what
> > drivers want anyway, and those who don't can open code it.
> >
> > Or is there an issue with that?
>
> It'll need more careful testing to make sure we don't have unwanted side
> effects when just doing it for everyone. And I guess most drivers don't
> care much because their hardware ignores vga port writes once they are
> switched out of vga text mode.
>
> Dunno why i915 needs this.
The problem isn't loading, it's unloading again. If you boot with vgacon,
but no fbdev driver (which iirc also has magic code to throw out the vga
console), then when you unload your kms driver vgacon kicks back in. And a
pile of things go really sideways when that happens.
I have no idea whether it's just intel hw or maybe pci decoding or
something else, but seems like good practice to kick out all existing
drivers, to make sure they can never get at the hw again.
So don't think it'll hurt to do this for everyone. But yeah maybe we can
do that as a follow-up (and convert i915 over), dunno.
-Daniel
> In case of qxl it is more a historical leftover. The very first qxl
> device revision had no explicit qxl command to switch from qxl native
> mode back to vga compatibility mode, vga port access was used for that
> instead. It's long fixed, but the qxl device still has that quirk for
> compatibility with very old guest drivers.
>
> cheers,
> Gerd
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH v2 2/2] drm/qxl: kick out vgacon
From: Gerd Hoffmann @ 2019-02-21 15:11 UTC (permalink / raw)
To: dri-devel, Dave Airlie, David Airlie,
open list:DRM DRIVER FOR QXL VIRTUAL GPU,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, open list
In-Reply-To: <20190221122011.GP2665@phenom.ffwll.local>
Hi,
> I was thinking of checking whether pdev is a VGA class device and whether
> it decodes vga access, and in that case automatically calling
How can I figure that? Ok, class is easy, but decode? pci.h offers
functions to set vga decode but not to get that info ...
thanks,
Gerd
^ permalink raw reply
* Re: [PATCH v2 2/2] drm/qxl: kick out vgacon
From: Daniel Vetter @ 2019-02-21 15:17 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: David Airlie, open list, dri-devel,
open list:DRM DRIVER FOR QXL VIRTUAL GPU,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, Dave Airlie
In-Reply-To: <20190221151139.ul2ihzd2yi4m47tf@sirius.home.kraxel.org>
On Thu, Feb 21, 2019 at 4:11 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> Hi,
>
> > I was thinking of checking whether pdev is a VGA class device and whether
> > it decodes vga access, and in that case automatically calling
>
> How can I figure that? Ok, class is easy, but decode? pci.h offers
> functions to set vga decode but not to get that info ...
PCI_COMMAND_MEM and PCI_COMMAND_IO. There doesn't seem to be any
separate bits really. That's at least what I've gleaned from vgaarb.c.
The magic legacy vga decode bits only seem to exist on bridges, maybe
we can extract that logic from vgaarb.c (yes this is all a bit
spiralling out of control).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 2/2] drm/bochs: Drop best_encoder
From: Daniel Vetter @ 2019-02-21 15:58 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, virtualization, Daniel Vetter
In-Reply-To: <20190221155857.19773-1-daniel.vetter@ffwll.ch>
This is the default for atomic drivers.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/bochs/bochs_kms.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c
index 9cd82e3631fb..9e7cd6b34106 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -214,20 +214,9 @@ static enum drm_mode_status bochs_connector_mode_valid(struct drm_connector *con
return MODE_OK;
}
-static struct drm_encoder *
-bochs_connector_best_encoder(struct drm_connector *connector)
-{
- int enc_id = connector->encoder_ids[0];
- /* pick the encoder ids */
- if (enc_id)
- return drm_encoder_find(connector->dev, NULL, enc_id);
- return NULL;
-}
-
static const struct drm_connector_helper_funcs bochs_connector_connector_helper_funcs = {
.get_modes = bochs_connector_get_modes,
.mode_valid = bochs_connector_mode_valid,
- .best_encoder = bochs_connector_best_encoder,
};
static const struct drm_connector_funcs bochs_connector_connector_funcs = {
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] drm/bochs: Fix the ID mismatch error
From: Alistair Francis @ 2019-02-21 18:44 UTC (permalink / raw)
To: kraxel@redhat.com
Cc: david.abdurachmanov@gmail.com, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org, Alistair Francis,
linux-riscv@lists.infradead.org
In-Reply-To: <20190221115227.ipwjpn3xm4q7jfg2@sirius.home.kraxel.org>
On Thu, Feb 21, 2019 at 3:52 AM kraxel@redhat.com <kraxel@redhat.com> wrote:
>
> On Thu, Feb 21, 2019 at 12:33:03AM +0000, Alistair Francis wrote:
> > When running RISC-V QEMU with the Bochs device attached via PCIe the
> > probe of the Bochs device fails with:
> > [drm:bochs_hw_init] *ERROR* ID mismatch
> >
> > This was introduced by this commit:
> > 7780eb9ce8 bochs: convert to drm_dev_register
> >
> > To fix the error we ensure that pci_enable_device() is called before
> > bochs_load().
> >
> > Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
> > Reported-by: David Abdurachmanov <david.abdurachmanov@gmail.com>
>
> Pushed to drm-misc-fixes.
Thanks. Any chance this will make it into 5.0?
Alistair
>
> thanks,
> Gerd
>
^ permalink raw reply
* Re: [PATCH] VMCI: Support upto 64-bit PPNs
From: gregkh @ 2019-02-21 19:42 UTC (permalink / raw)
To: Vishnu DASA
Cc: Pv-drivers, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <8C694A7E-488C-42A9-83F8-AA4FB4E57A5A@vmware.com>
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Thu, Feb 21, 2019 at 07:26:29PM +0000, Vishnu DASA wrote:
> Hi Greg,
> Sounds like a good idea to use the BIT() macro but can I do that in a
> separate change to cover the entire file (and perhaps other vmci files
> too)?
Yes, that would be fine.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v7 0/7] Add virtio-iommu driver
From: Thiago Jung Bauermann @ 2019-02-21 21:57 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: mark.rutland, devicetree, tnowicki, virtio-dev,
Jean-Philippe Brucker, linux-pci, linuxppc-dev, will.deacon,
virtualization, marc.zyngier, iommu, robh+dt, bhelgaas,
robin.murphy, kvmarm
In-Reply-To: <20190129135345-mutt-send-email-mst@kernel.org>
Michael S. Tsirkin <mst@redhat.com> writes:
> On Mon, Jan 21, 2019 at 11:29:05AM +0000, Jean-Philippe Brucker wrote:
>> Hi,
>>
>> On 18/01/2019 15:51, Michael S. Tsirkin wrote:
>> >
>> > On Tue, Jan 15, 2019 at 12:19:52PM +0000, Jean-Philippe Brucker wrote:
>> >> Implement the virtio-iommu driver, following specification v0.9 [1].
>> >>
>> >> This is a simple rebase onto Linux v5.0-rc2. We now use the
>> >> dev_iommu_fwspec_get() helper introduced in v5.0 instead of accessing
>> >> dev->iommu_fwspec, but there aren't any functional change from v6 [2].
>> >>
>> >> Our current goal for virtio-iommu is to get a paravirtual IOMMU working
>> >> on Arm, and enable device assignment to guest userspace. In this
>> >> use-case the mappings are static, and don't require optimal performance,
>> >> so this series tries to keep things simple. However there is plenty more
>> >> to do for features and optimizations, and having this base in v5.1 would
>> >> be good. Given that most of the changes are to drivers/iommu, I believe
>> >> the driver and future changes should go via the IOMMU tree.
>> >>
>> >> You can find Linux driver and kvmtool device on v0.9.2 branches [3],
>> >> module and x86 support on virtio-iommu/devel. Also tested with Eric's
>> >> QEMU device [4]. Please note that the series depends on Robin's
>> >> probe-deferral fix [5], which will hopefully land in v5.0.
>> >>
>> >> [1] Virtio-iommu specification v0.9, sources and pdf
>> >> git://linux-arm.org/virtio-iommu.git virtio-iommu/v0.9
>> >> http://jpbrucker.net/virtio-iommu/spec/v0.9/virtio-iommu-v0.9.pdf
>> >>
>> >> [2] [PATCH v6 0/7] Add virtio-iommu driver
>> >> https://lists.linuxfoundation.org/pipermail/iommu/2018-December/032127.html
>> >>
>> >> [3] git://linux-arm.org/linux-jpb.git virtio-iommu/v0.9.2
>> >> git://linux-arm.org/kvmtool-jpb.git virtio-iommu/v0.9.2
>> >>
>> >> [4] [RFC v9 00/17] VIRTIO-IOMMU device
>> >> https://www.mail-archive.com/qemu-devel@nongnu.org/msg575578.html
>> >>
>> >> [5] [PATCH] iommu/of: Fix probe-deferral
>> >> https://www.spinics.net/lists/arm-kernel/msg698371.html
>> >
>> > Thanks for the work!
>> > So really my only issue with this is that there's no
>> > way for the IOMMU to describe the devices that it
>> > covers.
>> >
>> > As a result that is then done in a platform-specific way.
>> >
>> > And this means that for example it does not solve the problem that e.g.
>> > some power people have in that their platform simply does not have a way
>> > to specify which devices are covered by the IOMMU.
>>
>> Isn't power using device tree? I haven't looked much at power because I
>> was told a while ago that they already paravirtualize their IOMMU and
>> don't need virtio-iommu, except perhaps for some legacy platforms. Or
>> something along those lines. But I would certainly be interested in
>> enabling the IOMMU for more architectures.
>
> I have CC'd the relevant ppc developers, let's see what do they think.
I'm far from being an expert, but what could be very useful for us is to
have a way for the guest to request IOMMU bypass for a device.
From what I understand, the pSeries platform used by POWER guests always
puts devices behind an IOMMU, so at least for current systems a
description of which devices are covered by the IOMMU would always say
"all of them".
>> As for the enumeration problem, I still don't think we can get much
>> better than DT and ACPI as solutions (and IMO they are necessary to make
>> this device portable). But I believe that getting DT and ACPI support is
>> just a one-off inconvenience. That is, once the required bindings are
>> accepted, any future extension can then be done at the virtio level with
>> feature bits and probe requests, without having to update ACPI or DT.
There is a device tree binding that can specify devices connected to a
given IOMMU in Documentation/devicetree/bindings/iommu/iommu.txt.
I don't believe POWER machines use it though.
>> Thanks,
>> Jean
>>
>> > Solving that problem would make me much more excited about
>> > this device.
>> >
>> > On the other hand I can see that while there have been some
>> > developments most of the code has been stable for quite a while now.
>> >
>> > So what I am trying to do right about now, is making a small module that
>> > loads early and pokes at the IOMMU sufficiently to get the data about
>> > which devices use the IOMMU out of it using standard virtio config
>> > space. IIUC it's claimed to be impossible without messy changes to the
>> > boot sequence.
>> >
>> > If I succeed at least on some platforms I'll ask that this design is
>> > worked into this device, minimizing info that goes through DT/ACPI. If
>> > I see I can't make it in time to meet the next merge window, I plan
>> > merging the existing patches using DT (barring surprises).
>> >
>> > As I only have a very small amount of time to spend on this attempt, If
>> > someone else wants to try doing that in parallel, that would be great!
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v7 0/7] Add virtio-iommu driver
From: Thiago Jung Bauermann @ 2019-02-21 22:18 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: Mark Rutland, virtio-dev@lists.oasis-open.org,
tnowicki@caviumnetworks.com, mst@redhat.com, Marc Zyngier,
linux-pci@vger.kernel.org, Joerg Roedel, Will Deacon,
virtualization@lists.linux-foundation.org,
iommu@lists.linux-foundation.org, robh+dt@kernel.org,
kvmarm@lists.cs.columbia.edu, bhelgaas@google.com, Robin Murphy,
devicetree@vger.kernel.org
In-Reply-To: <a6315ab3-bffb-7470-365d-b26df6524bda@arm.com>
Hello Jean-Philippe,
Jean-Philippe Brucker <jean-philippe.brucker@arm.com> writes:
> Makes sense, though I think other virtio devices have been developed a
> little more organically: device and driver code got upstreamed first,
> and then the specification describing their interface got merged into
> the standard. For example I believe that code for crypto, input and GPU
> devices were upstreamed long before the specification was merged. Once
> an implementation is upstream, the interface is expected to be
> backward-compatible (all subsequent changes are introduced using feature
> bits).
>
> So I've been working with this process in mind, also described by Jens
> at KVM forum 2017 [3]:
> (1) Reserve a device ID, and get that merged into virtio (ID 23 for
> virtio-iommu was reserved last year)
> (2) Open-source an implementation (this driver and Eric's device)
> (3) Formalize and upstream the device specification
>
> But I get that some overlap between (2) and (3) would have been better.
> So far the spec document has been reviewed mainly from the IOMMU point
> of view, and might require more changes to be in line with the other
> virtio devices -- hopefully just wording changes. I'll kick off step
> (3), but I think the virtio folks are a bit busy with finalizing the 1.1
> spec so I expect it to take a while.
I read v0.9 of the spec and have some minor comments, hope this is a
good place to send them:
1. In section 2.6.2, one reads
If the VIRTIO_IOMMU_F_INPUT_RANGE feature is offered and the range
described by fields virt_start and virt_end doesn’t fit in the range
described by input_range, the device MAY set status to VIRTIO_-
IOMMU_S_RANGE and ignore the request.
Shouldn't int say "If the VIRTIO_IOMMU_F_INPUT_RANGE feature is
negotiated" instead?
2. There's a typo at the end of section 2.6.5:
The VIRTIO_IOMMU_MAP_F_MMIO flag is a memory type rather than a
protection lag.
s/lag/flag/
3. In section 3.1.2.1.1, the viommu compatible field says "virtio,mmio".
Shouldn't it say "virtio,mmio-iommu" instead, to be consistent with
"virtio,pci-iommu"?
4. There's a typo in section 3.3:
A host bridge may limit the input address space – transaction
accessing some addresses won’t reach the physical IOMMU.
s/transaction/transactions/
I also have one last comment which you may freely ignore, considering
it's clearly just personal opinion and also considering that the
specification is mature at this point: it specifies memory ranges by
specifying start and end addresses. My experience has been that this is
error prone, leading to confusion and bugs regarding whether the end
address is inclusive or exclusive. I tend to prefer expressing memory
ranges by specifying a start address and a length, which eliminates
ambiguity.
--
Thiago Jung Bauermann
IBM Linux Technology Center
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] drm/qxl: unbind vgacon
From: kbuild test robot @ 2019-02-21 23:37 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: David Airlie, open list, dri-devel,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, Dave Airlie,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, kbuild-all
In-Reply-To: <20190220143640.9970-1-kraxel@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]
Hi Gerd,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0-rc4 next-20190221]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Gerd-Hoffmann/drm-qxl-unbind-vgacon/20190222-030117
config: x86_64-randconfig-l3-02212045 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> ERROR: "dummy_con" [drivers/gpu/drm/qxl/qxl.ko] undefined!
>> ERROR: "do_take_over_console" [drivers/gpu/drm/qxl/qxl.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29867 bytes --]
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)
From: Siwei Liu @ 2019-02-22 1:14 UTC (permalink / raw)
To: Jiri Pirko
Cc: Alexander Duyck, virtio-dev, Michael S. Tsirkin, Jakub Kicinski,
Sridhar Samudrala, virtualization, liran.alon, Netdev, si-wei liu,
David Miller
In-Reply-To: <20180411075334.GK2028@nanopsycho>
Sorry for replying to this ancient thread. There was some remaining
issue that I don't think the initial net_failover patch got addressed
cleanly, see:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
The renaming of 'eth0' to 'ens4' fails because the udev userspace was
not specifically writtten for such kernel automatic enslavement.
Specifically, if it is a bond or team, the slave would typically get
renamed *before* virtual device gets created, that's what udev can
control (without getting netdev opened early by the other part of
kernel) and other userspace components for e.g. initramfs,
init-scripts can coordinate well in between. The in-kernel
auto-enslavement of net_failover breaks this userspace convention,
which don't provides a solution if user care about consistent naming
on the slave netdevs specifically.
Previously this issue had been specifically called out when IFF_HIDDEN
and the 1-netdev was proposed, but no one gives out a solution to this
problem ever since. Please share your mind how to proceed and solve
this userspace issue if netdev does not welcome a 1-netdev model.
On Wed, Apr 11, 2018 at 12:53 AM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Tue, Apr 10, 2018 at 11:26:08PM CEST, stephen@networkplumber.org wrote:
> >On Tue, 10 Apr 2018 11:59:50 -0700
> >Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
> >
> >> Use the registration/notification framework supported by the generic
> >> bypass infrastructure.
> >>
> >> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> >> ---
> >
> >Thanks for doing this. Your current version has couple show stopper
> >issues.
> >
> >First, the slave device is instantly taking over the slave.
> >This doesn't allow udev/systemd to do its device rename of the slave
> >device. Netvsc uses a delayed work to workaround this.
>
> Wait. Why the fact a device is enslaved has to affect the udev in any
> way? If it does, smells like a bug in udev.
See above for clarifications.
Thanks,
>
>
> >
> >Secondly, the select queue needs to call queue selection in VF.
> >The bonding/teaming logic doesn't work well for UDP flows.
> >Commit b3bf5666a510 ("hv_netvsc: defer queue selection to VF")
> >fixed this performance problem.
> >
> >Lastly, more indirection is bad in current climate.
> >
> >I am not completely adverse to this but it needs to be fast, simple
> >and completely transparent.
^ permalink raw reply
* Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)
From: Michael S. Tsirkin @ 2019-02-22 1:39 UTC (permalink / raw)
To: Siwei Liu
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski,
Sridhar Samudrala, virtualization, liran.alon, Netdev, si-wei liu,
David Miller
In-Reply-To: <CADGSJ214RJV_zWVBGv0Ydo=CJj6WESTYAH=PpaYLFHdtWVrm3g@mail.gmail.com>
On Thu, Feb 21, 2019 at 05:14:44PM -0800, Siwei Liu wrote:
> Sorry for replying to this ancient thread. There was some remaining
> issue that I don't think the initial net_failover patch got addressed
> cleanly, see:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
>
> The renaming of 'eth0' to 'ens4' fails because the udev userspace was
> not specifically writtten for such kernel automatic enslavement.
> Specifically, if it is a bond or team, the slave would typically get
> renamed *before* virtual device gets created, that's what udev can
> control (without getting netdev opened early by the other part of
> kernel) and other userspace components for e.g. initramfs,
> init-scripts can coordinate well in between. The in-kernel
> auto-enslavement of net_failover breaks this userspace convention,
> which don't provides a solution if user care about consistent naming
> on the slave netdevs specifically.
>
> Previously this issue had been specifically called out when IFF_HIDDEN
> and the 1-netdev was proposed, but no one gives out a solution to this
> problem ever since. Please share your mind how to proceed and solve
> this userspace issue if netdev does not welcome a 1-netdev model.
Above says:
there's no motivation in the systemd/udevd community at
this point to refactor the rename logic and make it work well with
3-netdev.
What would the fix be? Skip slave devices?
--
MST
^ permalink raw reply
* Re: [PATCH] drm/qxl: unbind vgacon
From: kbuild test robot @ 2019-02-22 1:39 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: David Airlie, open list, dri-devel,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, Dave Airlie,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, kbuild-all
In-Reply-To: <20190220143640.9970-1-kraxel@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]
Hi Gerd,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0-rc4 next-20190221]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Gerd-Hoffmann/drm-qxl-unbind-vgacon/20190222-030117
config: x86_64-randconfig-m2-02211051 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
ld: drivers/gpu/drm/qxl/qxl_drv.o: in function `qxl_pci_probe':
>> drivers/gpu/drm/qxl/qxl_drv.c:94: undefined reference to `dummy_con'
>> ld: drivers/gpu/drm/qxl/qxl_drv.c:94: undefined reference to `do_take_over_console'
vim +94 drivers/gpu/drm/qxl/qxl_drv.c
61
62 static int
63 qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
64 {
65 struct qxl_device *qdev;
66 int ret;
67
68 if (pdev->revision < 4) {
69 DRM_ERROR("qxl too old, doesn't support client_monitors_config,"
70 " use xf86-video-qxl in user mode");
71 return -EINVAL; /* TODO: ENODEV ? */
72 }
73
74 qdev = kzalloc(sizeof(struct qxl_device), GFP_KERNEL);
75 if (!qdev)
76 return -ENOMEM;
77
78 ret = pci_enable_device(pdev);
79 if (ret)
80 goto free_dev;
81
82 ret = qxl_device_init(qdev, &qxl_driver, pdev);
83 if (ret)
84 goto disable_pci;
85
86 ret = qxl_modeset_init(qdev);
87 if (ret)
88 goto unload;
89
90 drm_kms_helper_poll_init(&qdev->ddev);
91
92 /* unbind vgacon to make sure it doesn't touch our vga registers */
93 console_lock();
> 94 ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, true);
95 console_unlock();
96
97 /* Complete initialization. */
98 ret = drm_dev_register(&qdev->ddev, ent->driver_data);
99 if (ret)
100 goto modeset_cleanup;
101
102 return 0;
103
104 modeset_cleanup:
105 qxl_modeset_fini(qdev);
106 unload:
107 qxl_device_fini(qdev);
108 disable_pci:
109 pci_disable_device(pdev);
110 free_dev:
111 kfree(qdev);
112 return ret;
113 }
114
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33583 bytes --]
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] drm/bochs: Fix the ID mismatch error
From: kraxel @ 2019-02-22 5:37 UTC (permalink / raw)
To: Alistair Francis
Cc: david.abdurachmanov@gmail.com, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org, Alistair Francis,
linux-riscv@lists.infradead.org
In-Reply-To: <CAKmqyKM_pb-riJ+jO65eT0SsVDxrstPOgurPuDf92Fd4C8k1Ug@mail.gmail.com>
On Thu, Feb 21, 2019 at 10:44:06AM -0800, Alistair Francis wrote:
> On Thu, Feb 21, 2019 at 3:52 AM kraxel@redhat.com <kraxel@redhat.com> wrote:
> >
> > On Thu, Feb 21, 2019 at 12:33:03AM +0000, Alistair Francis wrote:
> > > When running RISC-V QEMU with the Bochs device attached via PCIe the
> > > probe of the Bochs device fails with:
> > > [drm:bochs_hw_init] *ERROR* ID mismatch
> > >
> > > This was introduced by this commit:
> > > 7780eb9ce8 bochs: convert to drm_dev_register
> > >
> > > To fix the error we ensure that pci_enable_device() is called before
> > > bochs_load().
> > >
> > > Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
> > > Reported-by: David Abdurachmanov <david.abdurachmanov@gmail.com>
> >
> > Pushed to drm-misc-fixes.
>
> Thanks. Any chance this will make it into 5.0?
Hmm, we are damn close to the release, not sure there will be one more
drm-fixes pull req. But I've added a proper Fixes: tag, so even if the
patch misses the boat it should land in the stable branches shortly
thereafter.
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH] tpm: Add driver for TPM over virtio
From: Michael S. Tsirkin @ 2019-02-22 5:51 UTC (permalink / raw)
To: David Tolnay
Cc: dgreid, Jarkko Sakkinen, virtualization, Jason Gunthorpe,
Peter Huewe, apronin, linux-integrity
In-Reply-To: <388c5b80-21a7-1e91-a11f-3a1c1432368b@gmail.com>
On Thu, Feb 21, 2019 at 06:14:02PM -0800, David Tolnay wrote:
> Add a config TCG_VIRTIO_VTPM which enables a driver providing the guest
> kernel side of TPM over virtio.
>
> Use case: TPM support is needed for performing trusted work from within
> a virtual machine launched by Chrome OS.
>
> Tested inside crosvm, the Chrome OS virtual machine monitor. Crosvm's
> implementation of the virtio TPM device can be found in these two source
> files:
>
> - https://chromium.googlesource.com/chromiumos/platform/crosvm/+/18ce5713e6cb99c40aafec52b67c28ba12a44f31/devices/src/virtio/tpm.rs
> - https://chromium.googlesource.com/chromiumos/platform/crosvm/+/18ce5713e6cb99c40aafec52b67c28ba12a44f31/tpm2/src/lib.rs
>
> and is currently backed by the libtpm2 TPM simulator:
>
> - https://chromium.googlesource.com/chromiumos/third_party/tpm2/
>
> Reviewed-on: https://chromium-review.googlesource.com/1387655
> Reviewed-by: Andrey Pronin <apronin@chromium.org>
> Tested-by: David Tolnay <dtolnay@gmail.com>
> Signed-off-by: David Tolnay <dtolnay@gmail.com>
> ---
> UNRESOLVED:
> The driver assumes virtio device number VIRTIO_ID_TPM=31. If there is
> interest in accepting a virtio TPM driver into the kernel, the Chrome OS
> team will coordinate with the OASIS virtio technical committee to secure
> an agreed upon device number and include it in a later patchset.
I am not a tpm expert but I don't see why not.
> drivers/char/tpm/Kconfig | 9 +
> drivers/char/tpm/Makefile | 1 +
> drivers/char/tpm/tpm_virtio.c | 460 ++++++++++++++++++++++++++++++++++
Maintainer entry?
> 3 files changed, 470 insertions(+)
> create mode 100644 drivers/char/tpm/tpm_virtio.c
>
> diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> index 536e55d3919f..8997060e248e 100644
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -164,6 +164,15 @@ config TCG_VTPM_PROXY
> /dev/vtpmX and a server-side file descriptor on which the vTPM
> can receive commands.
>
> +config TCG_VIRTIO_VTPM
> + tristate "Virtio vTPM"
> + depends on TCG_TPM
> + help
> + This driver provides the guest kernel side of TPM over Virtio. If
> + you are building Linux to run inside of a hypervisor that supports
> + TPM over Virtio, say Yes and the virtualized TPM will be
> + accessible from the guest.
> +
>
> source "drivers/char/tpm/st33zp24/Kconfig"
> endif # TCG_TPM
> diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
> index a01c4cab902a..4f5d1071257a 100644
> --- a/drivers/char/tpm/Makefile
> +++ b/drivers/char/tpm/Makefile
> @@ -33,3 +33,4 @@ obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/
> obj-$(CONFIG_TCG_XEN) += xen-tpmfront.o
> obj-$(CONFIG_TCG_CRB) += tpm_crb.o
> obj-$(CONFIG_TCG_VTPM_PROXY) += tpm_vtpm_proxy.o
> +obj-$(CONFIG_TCG_VIRTIO_VTPM) += tpm_virtio.o
> diff --git a/drivers/char/tpm/tpm_virtio.c b/drivers/char/tpm/tpm_virtio.c
> new file mode 100644
> index 000000000000..f3239d983f18
> --- /dev/null
> +++ b/drivers/char/tpm/tpm_virtio.c
> @@ -0,0 +1,460 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 Google Inc.
> + *
> + * Author: David Tolnay <dtolnay@gmail.com>
> + *
> + * ---
> + *
> + * Device driver for TPM over virtio.
> + *
> + * This driver employs a single virtio queue to handle both send and recv. TPM
> + * commands are sent over virtio to the hypervisor during a TPM send operation
> + * and responses are received over the same queue during a recv operation.
> + *
> + * The driver contains a single buffer that is the only buffer we ever place on
> + * the virtio queue. Commands are copied from the caller's command buffer into
> + * the driver's buffer before handing off to virtio, and responses are received
> + * into the driver's buffer then copied into the caller's response buffer. This
> + * allows us to be resilient to timeouts. When a send or recv operation times
> + * out, the caller is free to destroy their buffer; we don't want the hypervisor
> + * continuing to perform reads or writes against that destroyed buffer.
> + *
> + * This driver does not support concurrent send and recv operations. Mutual
> + * exclusion is upheld by the tpm_mutex lock held in tpm-interface.c around the
> + * calls to chip->ops->send and chip->ops->recv.
> + *
> + * The intended hypervisor-side implementation is as follows.
> + *
> + * while true:
> + * await next virtio buffer.
> + * expect first descriptor in chain to be guest-to-host.
> + * read tpm command from that buffer.
> + * synchronously perform TPM work determined by the command.
> + * expect second descriptor in chain to be host-to-guest.
> + * write TPM response into that buffer.
> + * place buffer on virtio used queue indicating how many bytes written.
That's fine I think except generally it should be legal for guest
to split each buffer to several segments.
> + */
> +
> +#include <linux/virtio_config.h>
> +
> +#include "tpm.h"
> +
> +/*
> + * Timeout duration when waiting on the hypervisor to complete its end of the
> + * TPM operation. This timeout is relatively high because certain TPM operations
> + * can take dozens of seconds.
> + */
> +#define TPM_VIRTIO_TIMEOUT (120 * HZ)
Should we read this from device? E.g. a busy hypervisor might
take longer to respond ...
> +
> +struct vtpm_device {
> + /*
> + * Data structure for integration with the common code of the TPM driver
> + * in tpm-chip.c.
> + */
> + struct tpm_chip *chip;
> +
> + /*
> + * Virtio queue for sending TPM commands out of the virtual machine and
> + * receiving TPM responses back from the hypervisor.
> + */
> + struct virtqueue *vq;
> +
> + /*
> + * Completion that is notified when a virtio operation has been
> + * fulfilled by the hypervisor.
> + */
> + struct completion complete;
> +
> + /*
> + * Whether driver currently holds ownership of the virtqueue buffer.
> + * When false, the hypervisor is in the process of reading or writing
> + * the buffer and the driver must not touch it.
> + */
> + bool driver_has_buffer;
> +
> + /*
> + * Whether during the most recent TPM operation, a virtqueue_kick failed
> + * or a wait timed out.
> + *
> + * The next send or recv operation will attempt a kick upon seeing this
> + * status. That should clear up the queue in the case that the
> + * hypervisor became temporarily nonresponsive, such as by resource
> + * exhaustion on the host. The extra kick enables recovery from kicks
> + * going unnoticed by the hypervisor as well as recovery from virtio
> + * callbacks going unnoticed by the guest kernel.
Well not necessarily. E.g. virtqueue_kick does not
kick if hypervisor didn't enable notifications
(e.g. with event idx they get disabled automatically).
So it won't recover if hypervisor can discard
kicks.
I think this comment needs clarification.
> + */
> + bool needs_kick;
> +
> + /* Number of bytes available to read from the virtqueue buffer. */
> + unsigned int readable;
> +
> + /*
> + * Buffer in which all virtio transfers take place. Buffer size is the
> + * maximum legal TPM command or response message size.
> + */
> + u8 virtqueue_buffer[TPM_BUFSIZE];
> +};
> +
> +/*
> + * Wait for ownership of the virtqueue buffer.
> + *
> + * The why-string should begin with "waiting to..." or "waiting for..." with no
> + * trailing newline. It will appear in log output.
> + *
> + * Returns zero for success, otherwise negative error.
> + */
> +static int vtpm_wait_for_buffer(struct vtpm_device *dev, const char *why)
> +{
> + int ret;
> + bool did_kick;
> + struct tpm_chip *chip = dev->chip;
> + unsigned long deadline = jiffies + TPM_VIRTIO_TIMEOUT;
> +
> + /* Kick queue if needed. */
> + if (dev->needs_kick) {
> + did_kick = virtqueue_kick(dev->vq);
> + if (!did_kick) {
> + dev_notice(&chip->dev, "kick failed; will retry\n");
> + return -EBUSY;
> + }
> + dev->needs_kick = false;
> + }
> +
> + while (!dev->driver_has_buffer) {
> + unsigned long now = jiffies;
> +
> + /* Check timeout, otherwise `deadline - now` may underflow. */
> + if time_after_eq(now, deadline) {
> + dev_warn(&chip->dev, "timed out %s\n", why);
> + dev->needs_kick = true;
> + return -ETIMEDOUT;
> + }
> +
> + /*
> + * Wait to be signaled by virtio callback.
> + *
> + * Positive ret is jiffies remaining until timeout when the
> + * completion occurred, which means successful completion. Zero
> + * ret is timeout. Negative ret is error.
> + */
> + ret = wait_for_completion_killable_timeout(
> + &dev->complete, deadline - now);
> +
> + /* Log if completion did not occur. */
> + if (ret == -ERESTARTSYS) {
> + /* Not a warning if it was simply interrupted. */
> + dev_dbg(&chip->dev, "interrupted %s\n", why);
> + } else if (ret == 0) {
> + dev_warn(&chip->dev, "timed out %s\n", why);
> + ret = -ETIMEDOUT;
Should we check NEEDS_RESET bit and try to reset the device?
Or is that too drastic?
> + } else if (ret < 0) {
> + dev_warn(&chip->dev, "failed while %s: error %d\n",
> + why, -ret);
> + }
> +
> + /*
> + * Return error if completion did not occur. Schedule kick to be
> + * retried at the start of the next send/recv to help unblock
> + * the queue.
> + */
> + if (ret < 0) {
> + dev->needs_kick = true;
> + return ret;
> + }
> +
> + /* Completion occurred. Expect response buffer back. */
> + if (virtqueue_get_buf(dev->vq, &dev->readable)) {
> + dev->driver_has_buffer = true;
> +
> + if (dev->readable > TPM_BUFSIZE) {
> + dev_crit(&chip->dev,
> + "hypervisor bug: response exceeds max size, %u > %u\n",
> + dev->readable,
> + (unsigned int) TPM_BUFSIZE);
> + dev->readable = TPM_BUFSIZE;
> + return -EPROTO;
> + }
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int vtpm_op_send(struct tpm_chip *chip, u8 *caller_buf, size_t len)
> +{
> + int ret;
> + bool did_kick;
> + struct scatterlist sg_outbuf, sg_inbuf;
> + struct scatterlist *sgs[2] = { &sg_outbuf, &sg_inbuf };
> + struct vtpm_device *dev = dev_get_drvdata(&chip->dev);
> + u8 *virtqueue_buf = dev->virtqueue_buffer;
> +
> + dev_dbg(&chip->dev, __func__ " %zu bytes\n", len);
> +
> + if (len > TPM_BUFSIZE) {
> + dev_err(&chip->dev,
> + "command is too long, %zu > %zu\n",
> + len, (size_t) TPM_BUFSIZE);
> + return -EINVAL;
> + }
> +
> + /*
> + * Wait until hypervisor relinquishes ownership of the virtqueue buffer.
> + *
> + * This may block if the previous recv operation timed out in the guest
> + * kernel but is still being processed by the hypervisor. Also may block
> + * if send operations are performed back-to-back, such as if something
> + * in the caller failed in between a send and recv.
> + *
> + * During normal operation absent of any errors or timeouts, this does
> + * not block.
> + */
> + ret = vtpm_wait_for_buffer(dev, "waiting to begin send");
> + if (ret)
> + return ret;
> +
> + /* Driver owns virtqueue buffer and may now write into it. */
> + memcpy(virtqueue_buf, caller_buf, len);
> +
> + /*
> + * Enqueue the virtqueue buffer once as outgoing virtio data (written by
> + * the virtual machine and read by the hypervisor) and again as incoming
> + * data (written by the hypervisor and read by the virtual machine).
> + * This step moves ownership of the virtqueue buffer from driver to
> + * hypervisor.
> + *
> + * Note that we don't know here how big of a buffer the caller will use
> + * with their later call to recv. We allow the hypervisor to write up to
> + * the TPM max message size. If the caller ends up using a smaller
> + * buffer with recv that is too small to hold the entire response, the
> + * recv will return an error. This conceivably breaks TPM
> + * implementations that want to produce a different verbosity of
> + * response depending on the receiver's buffer size.
> + */
> + sg_init_one(&sg_outbuf, virtqueue_buf, len);
> + sg_init_one(&sg_inbuf, virtqueue_buf, TPM_BUFSIZE);
> + ret = virtqueue_add_sgs(dev->vq, sgs, 1, 1, virtqueue_buf, GFP_KERNEL);
> + if (ret) {
> + dev_err(&chip->dev, "failed virtqueue_add_sgs\n");
> + return ret;
> + }
> +
> + /* Kick the other end of the virtqueue after having added a buffer. */
> + did_kick = virtqueue_kick(dev->vq);
> + if (!did_kick) {
> + dev->needs_kick = true;
> + dev_notice(&chip->dev, "kick failed; will retry\n");
> +
> + /*
> + * We return 0 anyway because what the caller doesn't know can't
> + * hurt them. They can call recv and it will retry the kick. If
> + * that works, everything is fine.
> + *
> + * If the retry in recv fails too, they will get -EBUSY from
> + * recv.
> + */
> + }
> +
> + /*
> + * Hypervisor is now processing the TPM command asynchronously. It will
> + * read the command from the output buffer and write the response into
> + * the input buffer (which are the same buffer). When done, it will send
> + * back the buffers over virtio and the driver's virtio callback will
> + * complete dev->complete so that we know the response is ready to be
> + * read.
> + *
> + * It is important to have copied data out of the caller's buffer into
> + * the driver's virtqueue buffer because the caller is free to destroy
> + * their buffer when this call returns. We can't avoid copying by
> + * waiting here for the hypervisor to finish reading, because if that
> + * wait times out, we return and the caller may destroy their buffer
> + * while the hypervisor is continuing to read from it.
> + */
> + dev->driver_has_buffer = false;
> + return 0;
> +}
> +
> +static int vtpm_op_recv(struct tpm_chip *chip, u8 *caller_buf, size_t len)
> +{
> + int ret;
> + struct vtpm_device *dev = dev_get_drvdata(&chip->dev);
> + u8 *virtqueue_buf = dev->virtqueue_buffer;
> +
> + dev_dbg(&chip->dev, __func__ "\n");
> +
> + /*
> + * Wait until the virtqueue buffer is owned by the driver.
> + *
> + * This will usually block while the hypervisor finishes processing the
> + * most recent TPM command.
> + */
> + ret = vtpm_wait_for_buffer(dev, "waiting for TPM response");
> + if (ret)
> + return ret;
> +
> + dev_dbg(&chip->dev, "received %u bytes\n", dev->readable);
> +
> + if (dev->readable > len) {
> + dev_notice(&chip->dev,
> + "TPM response is bigger than receiver's buffer: %u > %zu\n",
> + dev->readable, len);
> + return -EINVAL;
> + }
> +
> + /* Copy response over to the caller. */
> + memcpy(caller_buf, virtqueue_buf, dev->readable);
> +
> + return dev->readable;
> +}
> +
> +static void vtpm_op_cancel(struct tpm_chip *chip)
> +{
> + /*
> + * Cancel is not called in this driver's use of tpm-interface.c. It may
> + * be triggered through tpm-sysfs but that can be implemented as needed.
> + * Be aware that tpm-sysfs performs cancellation without holding the
> + * tpm_mutex that protects our send and recv operations, so a future
> + * implementation will need to consider thread safety of concurrent
> + * send/recv and cancel.
> + */
> + dev_notice(&chip->dev, "cancellation is not implemented\n");
> +}
> +
> +static u8 vtpm_op_status(struct tpm_chip *chip)
> +{
> + /*
> + * Status is for TPM drivers that want tpm-interface.c to poll for
> + * completion before calling recv. Usually this is when the hardware
> + * needs to be polled i.e. there is no other way for recv to block on
> + * the TPM command completion.
> + *
> + * Polling goes until `(status & complete_mask) == complete_val`. This
> + * driver defines both complete_mask and complete_val as 0 and blocks on
> + * our own completion object in recv instead.
> + */
> + return 0;
> +}
> +
> +static const struct tpm_class_ops vtpm_ops = {
> + .flags = TPM_OPS_AUTO_STARTUP,
> + .send = vtpm_op_send,
> + .recv = vtpm_op_recv,
> + .cancel = vtpm_op_cancel,
> + .status = vtpm_op_status,
> + .req_complete_mask = 0,
> + .req_complete_val = 0,
> +};
> +
> +static void vtpm_virtio_complete(struct virtqueue *vq)
> +{
> + struct virtio_device *vdev = vq->vdev;
> + struct vtpm_device *dev = vdev->priv;
> +
> + complete(&dev->complete);
> +}
> +
> +static int vtpm_probe(struct virtio_device *vdev)
> +{
> + int err;
> + struct vtpm_device *dev;
> + struct virtqueue *vq;
> + struct tpm_chip *chip;
> +
> + dev_dbg(&vdev->dev, __func__ "\n");
> +
> + dev = kzalloc(sizeof(struct vtpm_device), GFP_KERNEL);
> + if (!dev) {
> + err = -ENOMEM;
> + dev_err(&vdev->dev, "failed kzalloc\n");
> + goto err_dev_alloc;
> + }
> + vdev->priv = dev;
> +
> + vq = virtio_find_single_vq(vdev, vtpm_virtio_complete, "vtpm");
> + if (IS_ERR(vq)) {
> + err = PTR_ERR(vq);
> + dev_err(&vdev->dev, "failed virtio_find_single_vq\n");
> + goto err_virtio_find;
> + }
> + dev->vq = vq;
> +
> + chip = tpm_chip_alloc(&vdev->dev, &vtpm_ops);
> + if (IS_ERR(chip)) {
> + err = PTR_ERR(chip);
> + dev_err(&vdev->dev, "failed tpm_chip_alloc\n");
> + goto err_chip_alloc;
> + }
> + dev_set_drvdata(&chip->dev, dev);
> + chip->flags |= TPM_CHIP_FLAG_TPM2;
> + dev->chip = chip;
> +
> + init_completion(&dev->complete);
> + dev->driver_has_buffer = true;
> + dev->needs_kick = false;
> + dev->readable = 0;
> +
> + /*
> + * Required in order to enable vq use in probe function for auto
> + * startup.
> + */
> + virtio_device_ready(vdev);
> +
> + err = tpm_chip_register(dev->chip);
> + if (err) {
> + dev_err(&vdev->dev, "failed tpm_chip_register\n");
> + goto err_chip_register;
> + }
> +
> + return 0;
> +
> +err_chip_register:
> + put_device(&dev->chip->dev);
> +err_chip_alloc:
> + vdev->config->del_vqs(vdev);
> +err_virtio_find:
> + kfree(dev);
> +err_dev_alloc:
> + return err;
> +}
> +
> +static void vtpm_remove(struct virtio_device *vdev)
> +{
> + struct vtpm_device *dev = vdev->priv;
> +
> + /* Undo tpm_chip_register. */
> + tpm_chip_unregister(dev->chip);
> +
> + /* Undo tpm_chip_alloc. */
> + put_device(&dev->chip->dev);
> +
> + vdev->config->reset(vdev);
> + vdev->config->del_vqs(vdev);
> +
> + kfree(dev);
> +}
> +
> +#define VIRTIO_ID_TPM 31
> +
> +static struct virtio_device_id id_table[] = {
> + {
> + .device = VIRTIO_ID_TPM,
> + .vendor = VIRTIO_DEV_ANY_ID,
> + },
> + {},
> +};
Let's write
static struct virtio_device_id id_table[] = {
{ VIRTIO_ID_TPM, VIRTIO_DEV_ANY_ID },
{ 0 },
};
for consistency with other virtio devices.
> +
> +static struct virtio_driver vtpm_driver = {
> + .driver.name = KBUILD_MODNAME,
> + .driver.owner = THIS_MODULE,
> + .id_table = id_table,
> + .probe = vtpm_probe,
> + .remove = vtpm_remove,
Freeze/restore?
> +};
> +
> +module_virtio_driver(vtpm_driver);
> +
> +MODULE_AUTHOR("David Tolnay (dtolnay@gmail.com)");
> +MODULE_DESCRIPTION("Virtio vTPM Driver");
> +MODULE_VERSION("1.0");
> +MODULE_LICENSE("GPL");
> --
> 2.20.1
^ permalink raw reply
* Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)
From: Samudrala, Sridhar @ 2019-02-22 7:00 UTC (permalink / raw)
To: si-wei liu, Michael S. Tsirkin, Siwei Liu
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski, Netdev,
virtualization, liran.alon, David Miller
In-Reply-To: <581e4399-3969-aecd-e923-03bbc0880733@oracle.com>
[-- Attachment #1.1: Type: text/plain, Size: 2749 bytes --]
On 2/21/2019 7:33 PM, si-wei liu wrote:
>
>
> On 2/21/2019 5:39 PM, Michael S. Tsirkin wrote:
>> On Thu, Feb 21, 2019 at 05:14:44PM -0800, Siwei Liu wrote:
>>> Sorry for replying to this ancient thread. There was some remaining
>>> issue that I don't think the initial net_failover patch got addressed
>>> cleanly, see:
>>>
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
>>>
>>> The renaming of 'eth0' to 'ens4' fails because the udev userspace was
>>> not specifically writtten for such kernel automatic enslavement.
>>> Specifically, if it is a bond or team, the slave would typically get
>>> renamed *before* virtual device gets created, that's what udev can
>>> control (without getting netdev opened early by the other part of
>>> kernel) and other userspace components for e.g. initramfs,
>>> init-scripts can coordinate well in between. The in-kernel
>>> auto-enslavement of net_failover breaks this userspace convention,
>>> which don't provides a solution if user care about consistent naming
>>> on the slave netdevs specifically.
>>>
>>> Previously this issue had been specifically called out when IFF_HIDDEN
>>> and the 1-netdev was proposed, but no one gives out a solution to this
>>> problem ever since. Please share your mind how to proceed and solve
>>> this userspace issue if netdev does not welcome a 1-netdev model.
>> Above says:
>>
>> there's no motivation in the systemd/udevd community at
>> this point to refactor the rename logic and make it work well with
>> 3-netdev.
>>
>> What would the fix be? Skip slave devices?
>>
> There's nothing user can get if just skipping slave devices - the name
> is still unchanged and unpredictable e.g. eth0, or eth1 the next
> reboot, while the rest may conform to the naming scheme (ens3 and
> such). There's no way one can fix this in userspace alone - when the
> failover is created the enslaved netdev was opened by the kernel
> earlier than the userspace is made aware of, and there's no
> negotiation protocol for kernel to know when userspace has done
> initial renaming of the interface. I would expect netdev list should
> at least provide the direction in general for how this can be solved...
>
Is there an issue if slave device names are not predictable? The user/admin scripts are expected
to only work with the master failover device.
Moreover, you were suggesting hiding the lower slave devices anyway. There was some discussion
about moving them to a hidden network namespace so that they are not visible from the default namespace.
I looked into this sometime back, but did not find the right kernel api to create a network namespace within
kernel. If so, we could use this mechanism to simulate a 1-netdev model.
> -Siwei
>
>
[-- Attachment #1.2: Type: text/html, Size: 4246 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v2 2/2] drm/qxl: kick out vgacon
From: Gerd Hoffmann @ 2019-02-22 7:14 UTC (permalink / raw)
To: Daniel Vetter
Cc: David Airlie, open list, dri-devel,
open list:DRM DRIVER FOR QXL VIRTUAL GPU,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, Dave Airlie
In-Reply-To: <CAKMK7uE+YzvBuaJVrNc0VzTQKmnDzNMoZDXohrh0M+PAfRFcBw@mail.gmail.com>
Hi,
> PCI_COMMAND_MEM and PCI_COMMAND_IO. There doesn't seem to be any
> separate bits really. That's at least what I've gleaned from vgaarb.c.
> The magic legacy vga decode bits only seem to exist on bridges, maybe
> we can extract that logic from vgaarb.c (yes this is all a bit
> spiralling out of control).
Also makes me wonder whenever vgaarb is the better place (compared to
drm_fb_helper). Tried that, doesn't look too bad, should continue
working with CONFIG_FB=n. Will send patches in a moment.
cheers,
Gerd
^ permalink raw reply
* [PATCH v4 2/2] drm/qxl: remove conflicting framebuffers earlier
From: Gerd Hoffmann @ 2019-02-22 7:16 UTC (permalink / raw)
To: dri-devel
Cc: David Airlie, open list, open list:DRM DRIVER FOR QXL VIRTUAL GPU,
daniel, open list:DRM DRIVER FOR QXL VIRTUAL GPU, Dave Airlie
In-Reply-To: <20190222071604.26024-1-kraxel@redhat.com>
Add error checking while being at it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/qxl/qxl_drv.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index bb81e310eb6d..578d867a81d5 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -79,6 +79,10 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (ret)
goto free_dev;
+ ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
+ if (ret)
+ goto disable_pci;
+
ret = qxl_device_init(qdev, &qxl_driver, pdev);
if (ret)
goto disable_pci;
@@ -94,7 +98,6 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (ret)
goto modeset_cleanup;
- drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
drm_fbdev_generic_setup(&qdev->ddev, 32);
return 0;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v4 2/2] drm/qxl: remove conflicting framebuffers earlier
From: Daniel Vetter @ 2019-02-22 9:51 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: David Airlie, open list, dri-devel,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, daniel,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, Dave Airlie
In-Reply-To: <20190222071604.26024-3-kraxel@redhat.com>
On Fri, Feb 22, 2019 at 08:16:04AM +0100, Gerd Hoffmann wrote:
> Add error checking while being at it.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/qxl/qxl_drv.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index bb81e310eb6d..578d867a81d5 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -79,6 +79,10 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (ret)
> goto free_dev;
>
> + ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
> + if (ret)
> + goto disable_pci;
> +
> ret = qxl_device_init(qdev, &qxl_driver, pdev);
> if (ret)
> goto disable_pci;
> @@ -94,7 +98,6 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (ret)
> goto modeset_cleanup;
>
> - drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
> drm_fbdev_generic_setup(&qdev->ddev, 32);
> return 0;
>
> --
> 2.9.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v5 3/3] drm/qxl: remove conflicting framebuffers earlier
From: Gerd Hoffmann @ 2019-02-22 11:06 UTC (permalink / raw)
To: dri-devel
Cc: David Airlie, intel-gfx, open list,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, daniel,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, Dave Airlie
In-Reply-To: <20190222110651.22109-1-kraxel@redhat.com>
Add error checking while being at it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/qxl/qxl_drv.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index bb81e310eb6d..578d867a81d5 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -79,6 +79,10 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (ret)
goto free_dev;
+ ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
+ if (ret)
+ goto disable_pci;
+
ret = qxl_device_init(qdev, &qxl_driver, pdev);
if (ret)
goto disable_pci;
@@ -94,7 +98,6 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (ret)
goto modeset_cleanup;
- drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
drm_fbdev_generic_setup(&qdev->ddev, 32);
return 0;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v7 0/7] Add virtio-iommu driver
From: Jean-Philippe Brucker @ 2019-02-22 12:18 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: Mark Rutland, virtio-dev@lists.oasis-open.org,
tnowicki@caviumnetworks.com, mst@redhat.com, Marc Zyngier,
linux-pci@vger.kernel.org, Joerg Roedel, Will Deacon,
virtualization@lists.linux-foundation.org,
iommu@lists.linux-foundation.org, robh+dt@kernel.org,
kvmarm@lists.cs.columbia.edu, bhelgaas@google.com, Robin Murphy,
devicetree@vger.kernel.org
In-Reply-To: <878sy8bx9o.fsf@morokweng.localdomain>
Hi Thiago,
On 21/02/2019 22:18, Thiago Jung Bauermann wrote:
>
> Hello Jean-Philippe,
>
> Jean-Philippe Brucker <jean-philippe.brucker@arm.com> writes:
>> Makes sense, though I think other virtio devices have been developed a
>> little more organically: device and driver code got upstreamed first,
>> and then the specification describing their interface got merged into
>> the standard. For example I believe that code for crypto, input and GPU
>> devices were upstreamed long before the specification was merged. Once
>> an implementation is upstream, the interface is expected to be
>> backward-compatible (all subsequent changes are introduced using feature
>> bits).
>>
>> So I've been working with this process in mind, also described by Jens
>> at KVM forum 2017 [3]:
>> (1) Reserve a device ID, and get that merged into virtio (ID 23 for
>> virtio-iommu was reserved last year)
>> (2) Open-source an implementation (this driver and Eric's device)
>> (3) Formalize and upstream the device specification
>>
>> But I get that some overlap between (2) and (3) would have been better.
>> So far the spec document has been reviewed mainly from the IOMMU point
>> of view, and might require more changes to be in line with the other
>> virtio devices -- hopefully just wording changes. I'll kick off step
>> (3), but I think the virtio folks are a bit busy with finalizing the 1.1
>> spec so I expect it to take a while.
>
> I read v0.9 of the spec and have some minor comments, hope this is a
> good place to send them:
Thanks a lot, I'll fix them in my next posting. Note that I recently
sent v0.10 to virtio-comment, to request inclusion into the standard [1]
but your comments still apply to v0.10.
[1]
https://lists.oasis-open.org/archives/virtio-comment/201901/msg00016.html
> 1. In section 2.6.2, one reads
>
> If the VIRTIO_IOMMU_F_INPUT_RANGE feature is offered and the range
> described by fields virt_start and virt_end doesn’t fit in the range
> described by input_range, the device MAY set status to VIRTIO_-
> IOMMU_S_RANGE and ignore the request.
>
> Shouldn't int say "If the VIRTIO_IOMMU_F_INPUT_RANGE feature is
> negotiated" instead?
Yes, that seems clearer and more consistent with other devices, I'll
change it. In this case "offered" is equivalent to "negotiated", because
the driver SHOULD accept the feature or else the device may refuse to
set FEATURES_OK. A valid input_range field generally indicates that the
device is incapable of creating mappings outside this range, and it's
important that the driver acknowledges it.
> 2. There's a typo at the end of section 2.6.5:
>
> The VIRTIO_IOMMU_MAP_F_MMIO flag is a memory type rather than a
> protection lag.
>
> s/lag/flag/
Fixed in v0.10
> 3. In section 3.1.2.1.1, the viommu compatible field says "virtio,mmio".
> Shouldn't it say "virtio,mmio-iommu" instead, to be consistent with
> "virtio,pci-iommu"?
"virtio,mmio" already exists, and allows the virtio-mmio driver to pick
up any virtio device. The device type is then discovered while probing,
and doesn't need to be in the compatible string.
"virtio,pci-iommu" is something I introduced specifically for the
virtio-iommu, since it's the only virtio-pci device that requires a
device tree node - to describe the IOMMU topology earlier than the PCI
probe. If we want symmetry I'd rather replace "virtio,pci-iommu" with
"virtio,pci", but it wouldn't be used by other virtio device types. And
I have to admit I'm reluctant to change this binding now, given that it
has been reviewed (patch 2/7) and is ready to go.
> 4. There's a typo in section 3.3:
>
> A host bridge may limit the input address space – transaction
> accessing some addresses won’t reach the physical IOMMU.
>
> s/transaction/transactions/
I'll fix it, thanks
> I also have one last comment which you may freely ignore, considering
> it's clearly just personal opinion and also considering that the
> specification is mature at this point: it specifies memory ranges by
> specifying start and end addresses. My experience has been that this is
> error prone, leading to confusion and bugs regarding whether the end
> address is inclusive or exclusive. I tend to prefer expressing memory
> ranges by specifying a start address and a length, which eliminates
> ambiguity.
While the initial versions had start and length, I changed it because it
cannot express the whole 64-bit range. If the guest wants to do
unmap-all (and the input range is 64-bit), then it can send a single
UNMAP request with start=0, end=~0ULL, which wouldn't be possible with
start and length. Arguably a very rare use-case, but one I've tried to
implement at least twice with VFIO :) I'll see if I can make it more
obvious that end is inclusive, since the word doesn't appear at all in
the current draft.
Thanks,
Jean
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)
From: Michael S. Tsirkin @ 2019-02-22 15:14 UTC (permalink / raw)
To: si-wei liu
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Jakub Kicinski,
Samudrala, Sridhar, virtualization, Siwei Liu, liran.alon, Netdev,
David Miller
In-Reply-To: <d9ef40a2-237b-0cce-4401-ecaeac4c602a@oracle.com>
On Thu, Feb 21, 2019 at 11:55:11PM -0800, si-wei liu wrote:
>
>
> On 2/21/2019 11:00 PM, Samudrala, Sridhar wrote:
> >
> >
> > On 2/21/2019 7:33 PM, si-wei liu wrote:
> > >
> > >
> > > On 2/21/2019 5:39 PM, Michael S. Tsirkin wrote:
> > > > On Thu, Feb 21, 2019 at 05:14:44PM -0800, Siwei Liu wrote:
> > > > > Sorry for replying to this ancient thread. There was some remaining
> > > > > issue that I don't think the initial net_failover patch got addressed
> > > > > cleanly, see:
> > > > >
> > > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
> > > > >
> > > > > The renaming of 'eth0' to 'ens4' fails because the udev userspace was
> > > > > not specifically writtten for such kernel automatic enslavement.
> > > > > Specifically, if it is a bond or team, the slave would typically get
> > > > > renamed *before* virtual device gets created, that's what udev can
> > > > > control (without getting netdev opened early by the other part of
> > > > > kernel) and other userspace components for e.g. initramfs,
> > > > > init-scripts can coordinate well in between. The in-kernel
> > > > > auto-enslavement of net_failover breaks this userspace convention,
> > > > > which don't provides a solution if user care about consistent naming
> > > > > on the slave netdevs specifically.
> > > > >
> > > > > Previously this issue had been specifically called out when IFF_HIDDEN
> > > > > and the 1-netdev was proposed, but no one gives out a solution to this
> > > > > problem ever since. Please share your mind how to proceed and solve
> > > > > this userspace issue if netdev does not welcome a 1-netdev model.
> > > > Above says:
> > > >
> > > > there's no motivation in the systemd/udevd community at
> > > > this point to refactor the rename logic and make it work well with
> > > > 3-netdev.
> > > >
> > > > What would the fix be? Skip slave devices?
> > > >
> > > There's nothing user can get if just skipping slave devices - the
> > > name is still unchanged and unpredictable e.g. eth0, or eth1 the
> > > next reboot, while the rest may conform to the naming scheme (ens3
> > > and such). There's no way one can fix this in userspace alone - when
> > > the failover is created the enslaved netdev was opened by the kernel
> > > earlier than the userspace is made aware of, and there's no
> > > negotiation protocol for kernel to know when userspace has done
> > > initial renaming of the interface. I would expect netdev list should
> > > at least provide the direction in general for how this can be
> > > solved...
I was just wondering what did you mean when you said
"refactor the rename logic and make it work well with 3-netdev" -
was there a proposal udev rejected?
Anyway, can we write a time diagram for what happens in which order that
leads to failure? That would help look for triggers that we can tie
into, or add new ones.
> > >
> > Is there an issue if slave device names are not predictable? The user/admin scripts are expected
> > to only work with the master failover device.
> Where does this expectation come from?
>
> Admin users may have ethtool or tc configurations that need to deal with
> predictable interface name. Third-party app which was built upon specifying
> certain interface name can't be modified to chase dynamic names.
>
> Specifically, we have pre-canned image that uses ethtool to fine tune VF
> offload settings post boot for specific workload. Those images won't work
> well if the name is constantly changing just after couple rounds of live
> migration.
It should be possible to specify the ethtool configuration on the
master and have it automatically propagated to the slave.
BTW this is something we should look at IMHO.
> > Moreover, you were suggesting hiding the lower slave devices anyway. There was some discussion
> > about moving them to a hidden network namespace so that they are not visible from the default namespace.
> > I looked into this sometime back, but did not find the right kernel api to create a network namespace within
> > kernel. If so, we could use this mechanism to simulate a 1-netdev model.
> Yes, that's one possible implementation (IMHO the key is to make 1-netdev
> model as much transparent to a real NIC as possible, while a hidden netns is
> just the vehicle). However, I recall there was resistance around this
> discussion that even the concept of hiding itself is a taboo for Linux
> netdev. I would like to summon potential alternatives before concluding
> 1-netdev is the only solution too soon.
>
> Thanks,
> -Siwei
Your scripts would not work at all then, right?
> >
> > > -Siwei
> > >
> > >
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox