* Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming
From: Dan Carpenter @ 2017-09-12 14:09 UTC (permalink / raw)
To: Emil Velikov
Cc: David Airlie, kernel-janitors, Linux-Kernel@Vger. Kernel. Org,
ML dri-devel, open list:VIRTIO GPU DRIVER, Dave Airlie,
Colin King
In-Reply-To: <CACvgo53vbGbvejkEnQuuB-ZuVfbzvSmAsx3Ovj-wMWMQE8ihXw@mail.gmail.com>
On Tue, Sep 12, 2017 at 03:02:04PM +0100, Emil Velikov wrote:
> That said, I'm not sure how useful the information is - perhaps it's
> better to drop it all together?
Or a WARN_ONCE().
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming
From: Gerd Hoffmann @ 2017-09-12 14:21 UTC (permalink / raw)
To: Dan Carpenter, Emil Velikov
Cc: David Airlie, kernel-janitors, Linux-Kernel@Vger. Kernel. Org,
ML dri-devel, open list:VIRTIO GPU DRIVER, Dave Airlie,
Colin King
In-Reply-To: <20170912140921.maegwq32x5a6jyql@mwanda>
On Tue, 2017-09-12 at 17:09 +0300, Dan Carpenter wrote:
> On Tue, Sep 12, 2017 at 03:02:04PM +0100, Emil Velikov wrote:
> > That said, I'm not sure how useful the information is - perhaps
> > it's
> > better to drop it all together?
>
> Or a WARN_ONCE().
It's userspace calling into the driver with invalid parameters.
IMO we should never WARN_ONCE() on something userspace can trigger.
I'd suggest to just drop the message altogether, simply throwing EINVAL
at userspace is perfectly fine IMHO.
cheers,
Gerd
^ permalink raw reply
* Re: [Qemu-devel] [RFC] Buffers/caches in VirtIO Balloon driver stats
From: Tomáš Golembiovský @ 2017-09-12 14:29 UTC (permalink / raw)
To: Wei Wang; +Cc: virtio-dev, kvm, Michael S. Tsirkin, qemu-devel, virtualization
In-Reply-To: <59A557B1.7080704@intel.com>
On Tue, 29 Aug 2017 20:01:53 +0800
Wei Wang <wei.w.wang@intel.com> wrote:
> On 08/29/2017 05:57 PM, Stefan Hajnoczi wrote:
> > On Sun, Aug 27, 2017 at 11:30:33PM +0200, Tomáš Golembiovský wrote:
> >> Hi,
> > I have CCed the relevant mailing lists and people most recently involved
> > in virtio-balloon discussions. Hopefully this will help get the right
> > people to see your questions.
> >
> >> We'd like to include information about reclaimable memory into the
> >> statistics in VirtiO Balloon driver. Namely, we'd like to include
> >> counters for bufferes and caches of Linux kernel. The patch itself is
> >> pretty trivial -- no problem there. But before we do that I'd like to
> >> get some input from the QEMU community.
> >>
> >> 1) Is there any reason not to have the stats there?
>
> Could you please share the usages of reclaimable memory via the stats?
I'll go ahead then and start sending patches. What would be the proper
course of action here? Send patch for the driver first, or send patch
for QEMU first or send both patches right away?
> >>
> >> 2) Considering the balloon device is multiplatform (Linux, BSD,
> >> Windows), is there a problem with including buffers/caches? These seem
> >> to be specific to the Linux virtual memory subsystem. Of course, other
> >> OSes could just report zeros. Are there some internal stats on those
> >> OSes that could be filled in? I don't now if such or similar statistic
> >> are available on BSD. On Windows only SystemCache stat looks like
> >> something relevant. Anyone familiar with those OSes has any suggestions?
> >>
> >>
>
> One of the solutions that I'm thinking about is to make virtio
> platform-ware.
This is not necessary. IIUC the driver does not need to send all the
stats. We can simply treat those stats as specific to Linux driver and
other drivers will not send them. Then QEMU will treat them as if zero
was reported.
>
> That is, the device by default supports
> VIRTIO_F_LINUX,
> VIRTIO_F_WINDOWS,
> VIRTIO_F_BSD.
>
> For the Linux driver, only VIRTIO_F_LINUX is supported, then we can
> have Linux specific driver implementations under that feature.
Since there were no suggestions for similar stats on other OSes I'd say
we treat the stats for buffers and caches as Linux specific. If there is
any need to send similar stats for other OSes we will add new stat fields
(specific for that particular OS).
Thanks,
Tomas
--
Tomáš Golembiovský <tgolembi@redhat.com>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [virtio-dev] packed ring layout proposal v3
From: Willem de Bruijn @ 2017-09-12 16:20 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtio-dev, virtualization
In-Reply-To: <20160915223915.qjlnlvf2w7u37bu3@redhat.com>
On Sun, Sep 10, 2017 at 1:06 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> This is an update from v2 version.
> Changes:
> - update event suppression mechanism
> - add wrap counter: DESC_WRAP flag in addition to
> DESC_DRIVER flag used for validity so device does not have to
> write out all used descriptors.
> - more options especially helpful for hardware implementations
> - in-order processing option due to popular demand
> - list of TODO items to consider as a follow-up, only two are
> open questions we need to descide now, marked as blocker,
> others are future enhancement ideas.
Perhaps this would make a good topic for a BoF session at the upcoming
netdev. A new ring structure can be useful elsewhere, too, such as for
af_packet v4.
>
> ---
>
> Performance analysis of this is in my kvm forum 2016 presentation.
> The idea is to have a r/w descriptor in a ring structure,
> replacing the used and available ring, index and descriptor
> buffer.
>
> Note: the following mode of operation will actually work
> without changes when descriptor rings do not overlap, with driver
> writing out available entries in a read-only driver descriptor ring,
> device writing used entries in a write-only device descriptor ring.
The ring is always read-write, as the consumer has to toggle the
DESC_DRIVER flag, right? Which mode are you referring to?
> TODO: does this have any value for some? E.g. as a security feature?
>
>
> * Descriptor ring:
>
> Driver writes descriptors with unique index values and DESC_DRIVER set in flags.
> Descriptors are written in a ring order: from start to end of ring,
> wrapping around to the beginning.
> Device writes used descriptors with correct len, index, and DESC_HW clear.
> Again descriptors are written in ring order. This might not be the same
> order of driver descriptors, and not all descriptors have to be written out.
Virtio rings are used in both directions between guest device driver and
host device, as well as in increasingly many situations outside vm i/o.
I suggest using producer and consumer instead of driver and device
when describing ring operations.
When working on the virtio-net tx path, having to invert all the documentation
in my head, because it is written from an rx point of view was a bit tricky ;-)
I would then also convert DESC_DRIVER to DESC_VALID or so.
> Driver and device are expected to maintain (internally) a wrap-around
> bit, starting at 0 and changing value each time they start writing out
> descriptors at the beginning of the ring. This bit is passed as
> DESC_WRAP bit in the flags field.
So, the flag effectively doubles the namespace of the id from 16 bit to
17 bit? Instead, how about using a larger identifier. Such as 32 bit.
This also future proofs the design for cases where the ring may grow
to exceed 65536 entries. Doing so is not a short term change, but it
ould avoid the need for indirect descriptors and give greated room
for out of order acknowledgement.
> Flags are always set/cleared last.
>
> Note that driver can write descriptors out in any order, but device
> will not execute descriptor X+1 until descriptor X has been
> read as valid.
Why this constraint on the ring?
> Driver operation:
>
> Driver makes descriptors available to device by writing out descriptors
> in the descriptor ring. Once ring is full, driver waits for device to
> use some descriptors before making more available.
>
> Descriptors can be used by device in any order, but must be read from
> ring in-order, and must be read completely before starting use. Thus,
> once a descriptor is used, driver can over-write both this descriptor
> and any descriptors which preceded it in the ring.
Does this mean that completing a descriptor by the consumer implicitly
completes all descriptors that precede it in the ring?
> Driver can detect use of descriptor either by device specific means
> (e.g. detect a buffer data change by device) or in a generic way
> by detecting that a used buffer has been written out by device.
I don't quite follow this.
> Driver writes out available scatter/gather descriptor entries in guest
> descriptor format:
>
>
> #define DESC_WRAP 0x0040
> #define DESC_DRIVER 0x0080
>
> struct desc {
> __le64 addr;
> __le32 len;
> __le16 index;
> __le16 flags;
> };
>
> Fields:
>
> addr - physical address of a s/g entry
> len - length of an entry
Is this ever larger than 16-bit? If not, then reducing to 16-bit allows
growing index to 32-bit.
> index - unique index. The low $\lceil log(N) \rceil - 1$
> bits of the index is a driver-supplied value which can have any value
> (under driver control). The high bits are reserved and should be
> set to 0.
>
> flags - descriptor flags.
>
> Descriptors written by driver have DESC_DRIVER set.
>
> Writing out this field makes the descriptor available for the device to use,
> so all other fields must be valid when it is written.
>
> DESC_WRAP - device uses this field to detect descriptor change by driver.
>
> Driver can use 1 bit to set direction
> /* This marks a descriptor as write-only (otherwise read-only). */
> #define VRING_DESC_F_WRITE 2
This is a per-ring flag, as opposed to the per-descriptor flags DESC_*.
Please make that explicit and state in which structure it is set.
>
>
> Device operation (using descriptors):
>
> Device is looking for descriptors in ring order. After detecting that
> the flags value has changed with DESC_DRIVER set and DESC_WRAP matching
> the wrap-around counter, it can start using the descriptors.
> Descriptors can be used in any order, but must be read from ring
> in-order. In other words device must not read descriptor X after it
> started using descriptor X+1.
Why? This is the same question as above, really. This seems like a
device constraint, not necessarily a constraint to impose on the ring
format.
> Further, all buffer descriptors must be
> read completely before device starts using the buffer.
>
> This because once a descriptor is used, driver can over-write both this
> descriptor and any preceeding descriptors in ring.
This does explain the above constraint. I guess that I just do not
understand the reason for this behavior.
> To help driver detect use of descriptors and to pass extra meta-data
> to driver, device writes out used entries in device descriptor format:
>
>
> #define DESC_WRAP 0x0040
> #define DESC_DRIVER 0x0080
>
> struct desc {
> __le64 reserved;
> __le32 len;
> __le16 index;
> __le16 flags;
> };
>
> Fields:
>
> reserved - can be any value, ignored by driver
> len - length written by device. only valid if VRING_DESC_F_WRITE is set
> len bytes of data from beginning of buffer are assumed to have been updated
> index - unique index copied from the driver descriptor that has been used.
> flags - descriptor flags.
>
> Descriptors written by device have DESC_DRIVER clear.
>
> Writing out this field notifies the driver that it can re-use the
> descriptor id. It is also a signal that driver can over-write the
> relevant descriptor (with the supplied id), and any other
>
> DESC_WRAP - driver uses this field to detect descriptor change by device.
>
> If device has used a buffer containing a write descriptor, it sets this bit:
> #define VRING_DESC_F_WRITE 2
>
> * Driver scatter/gather support
>
> Driver can use 1 bit to chain s/g entries in a request, similar to virtio 1.0:
>
> /* This marks a buffer as continuing in the next ring entry. */
> #define VRING_DESC_F_NEXT 1
Isn't this a descriptor flag, so DESC_NEXT?
>
> When driver descriptors are chained in this way, multiple
> descriptors are treated as a part of a single transaction
> containing an optional write buffer followed by an optional read buffer.
Can you elaborate on the last part about optional write and read buffer?
> All descriptors in the chain must have the same ID.
If so, then the explicit flag is not needed?
> Unlike virtio 1.0, use of this flag will be an optional feature
> so both devices and drivers can opt out of it.
> If they do, they can either negotiate indirect descriptors or use
> single-descriptor entries exclusively for buffers.
>
> Device might detect a partial descriptor chain (VRING_DESC_F_NEXT
> set but next descriptor not valid).
This can be forbidden, by requiring the producer to set the
DESC_DRIVER bit on the first descriptor only after the entire
chain has been written.
Do chains have to consist of consecutive descriptors?
> In that case it must not
> use any parts of the chain - it will later be completed by driver,
> but device is allowed to store the valid parts of the chain as
> driver is not allowed to change them anymore.
>
> Two options are available:
>
> Device can write out the same number of descriptors for the chain,
> setting VRING_DESC_F_NEXT for all but the last descriptor.
> Driver will ignore all used descriptors with VRING_DESC_F_NEXT bit set.
>
> Device only writes out a single descriptor for the whole chain.
> However, to keep device and driver in sync, it then skips a number of
> descriptors corresponding to the length of the chain before writing out
> the next used descriptor.
> After detecting a used descriptor driver must find out the length of the
> chain that it built in order to know where to look for the next
> device descriptor.
>
> * Indirect buffers
>
> Indirect buffer descriptors is an optional feature.
> These are always written by driver, not the device.
> Indirect buffers have a special flag bit set - like in virtio 1.0:
>
> /* This means the buffer contains a table of buffer descriptors. */
> #define VRING_DESC_F_INDIRECT 4
>
> VRING_DESC_F_WRITE and VRING_DESC_F_NEXT are always clear.
>
> len specifies the length of the indirect descriptor buffer in bytes
> and must be a multiple of 16.
Multiple of sizeof(struct indirect_desc).
Also, struct indirect_desc is identical to struct desc. No need for a
separate struct definition?
>
> Unlike virtio 1.0, the buffer pointed to is a table, not a list:
This is just a linear array, right?
> struct indirect_descriptor_table {
> /* The actual descriptors (16 bytes each) */
> struct indirect_desc desc[len / 16];
> };
>
> The first descriptor is located at start of the indirect descriptor
> table, additional indirect descriptors come immediately afterwards.
>
> struct indirect_desc {
> __le64 addr;
> __le32 len;
> __le16 reserved;
> __le16 flags;
> };
>
>
> DESC_F_WRITE is the only valid flag for descriptors in the indirect
> table. Others should be set to 0 and are ignored. reserved field is
> also set to 0 and should be ignored.
>
> TODO (blocker): virtio 1.0 allows a s/g entry followed by
> an indirect descriptor. Is this useful?
Sounds like unnecessary complexity.
> This support would be an optional feature, same as in virtio 1.0
>
> * Batching descriptors:
>
> virtio 1.0 allows passing a batch of descriptors in both directions, by
> incrementing the used/avail index by values > 1.
> At the moment only batching of used descriptors is used.
>
> We can support this by chaining a list of device descriptors through
> VRING_DESC_F_MORE flag. Device sets this bit to signal
> driver that this is part of a batch of used descriptors
> which are all part of a single transaction.
>
> Driver might detect a partial descriptor chain (VRING_DESC_F_MORE
> set but next descriptor not valid). In that case it must not
> use any parts of the chain - it will later be completed by device,
> but driver is allowed to store the valid parts of the chain as
> device is not allowed to change them anymore.
>
> Descriptor should not have both VRING_DESC_F_MORE and
> VRING_DESC_F_NEXT set.
>
> * Using descriptors in order
>
> Some devices can guarantee that descriptors are used in
> the order in which they were made available.
> This allows driver optimizations and can be negotiated through
> a feature bit.
>
> * Per ring flags
>
> It is useful to support features for some rings but not others.
> E.g. it's reasonable to use single buffers for RX rings but
> sg or indirect for TX rings of the network device.
> Generic configuration space will be extended so features can
> be negotiated per ring.
>
> * Selective use of descriptors
>
> As described above, descriptors with NEXT bit set are part of a
> scatter/gather chain and so do not have to cause device to write a used
> descriptor out.
>
> Similarly, driver can set a flag VRING_DESC_F_MORE in the descriptor to
> signal to device that it does not have to write out the used descriptor
> as it is part of a batch of descriptors. Device has two options (similar
> to VRING_DESC_F_NEXT):
>
> Device can write out the same number of descriptors for the batch,
> setting VRING_DESC_F_MORE for all but the last descriptor.
> Driver will ignore all used descriptors with VRING_DESC_F_MORE bit set.
>
> Device only writes out a single descriptor for the whole batch.
> However, to keep device and driver in sync, it then skips a number of
> descriptors corresponding to the length of the batch before writing out
> the next used descriptor.
> After detecting a used descriptor driver must find out the length of the
> batch that it built in order to know where to look for the next
> device descriptor.
>
>
> TODO (blocker): skipping descriptors for selective and
> scatter/gather seem to be only requested with in-order right now. Let's
> require in-order for this skipping? This will simplify the accounting
> by driver.
>
>
> * Interrupt/event suppression
>
> virtio 1.0 has two mechanisms for suppression but only
> one can be used at a time. we pack them together
> in a structure - one for interrupts, one for notifications:
>
> struct event {
> __le16 idx;
> __le16 flags;
> }
>
> Both fields would be optional, with a feature bit:
> VIRTIO_F_EVENT_IDX
> VIRTIO_F_EVENT_FLAGS
>
> Flags can be used like in virtio 1.0, by storing a special
> value there:
>
> #define VRING_F_EVENT_ENABLE 0x0
>
> #define VRING_F_EVENT_DISABLE 0x1
>
> Event index includes the index of the descriptor
> which should trigger the event, and the wrap counter
> in the high bit.
>
> In that case, interrupt triggers when descriptor is written at a given
> location in the ring (or skipped in case of NEXT/MORE).
>
> If both features are negotiated, a special flags value
> can be used to switch to event idx:
>
> #define VRING_F_EVENT_IDX 0x2
>
> * Available notification
>
> Driver currently writes out the queue number to device to
> kick off ring processing.
>
> As queue number is currently 16 bit, we can extend that
> to additionally include the offset within ring of the descriptor
> which triggered the kick event in bits 16 to 30,
> and the wrap counter in the high bit (31).
>
> Device is allowed to pre-fetch descriptors beyond the specified
> offset but is not required to do so.
>
>
>
> * TODO: interrupt coalescing
>
> Does it make sense just for networking or for all devices?
> If later should we make it a per ring or a global feature?
>
>
> * TODO: event index/flags in device memory?
>
> Should we move the event index/flags to device memory?
> Might be helpful for hardware configuration so they do not
> need to do DMA reads to check whether interrupt is needed.
Agreed. This also resembles physical devices more closely.
> OTOH maybe interrupt coalescing is sufficient for this.
>
>
> * TODO: Device specific descriptor flags
>
> We have a lot of unused space in the descriptor. This can be put to
> good use by reserving some flag bits for device use.
> For example, network device can set a bit to request
> that header in the descriptor is suppressed
> (in case it's all 0s anyway). This reduces cache utilization.
>
> Note: this feature can be supported in virtio 1.0 as well,
> as we have unused bits in both descriptor and used ring there.
>
> * TODO: Descriptor length in device descriptors
>
> Some devices use identically-sized buffers in all descriptors.
> Ignoring length for driver descriptors there could be an option too.
>
> * TODO: Writing at an offset
>
> Some devices might want to write into some descriptors
> at an offset, the offset would be in reserved field in the descriptor,
> possibly a descriptor flag could indicate this:
>
> #define VRING_DESC_F_OFFSET 0x0020
>
> How exactly to use the offset would be device specific,
> for example it can be used to align beginning of packet
> in the 1st buffer for mergeable buffers to cache line boundary
> while also aligning rest of buffers.
>
> * TODO: Non power-of-2 ring sizes
>
> As the ring simply wraps around, there's no reason to
> require ring size to be power of two.
> It can be made a separate feature though.
>
>
> TODO: limits on buffer alignment/size
>
> Seems to be useful for RX for networking.
> Is there a need to negotiate above in a generic way
> or is this a networking specific optimization?
>
> TODO: expose wrap counters to device for debugging
>
> TODO: expose last avail/used offsets to device/driver for debugging
>
> TODO: ability to reset individual rings
>
> ---
>
> Note: should this proposal be accepted and approved, one or more
> claims disclosed to the TC admin and listed on the Virtio TC
> IPR page https://www.oasis-open.org/committees/virtio/ipr.php
> might become Essential Claims.
> Note: the page above is unfortunately out of date and out of
> my hands. I'm in the process of updating ipr disclosures
> in github instead. Will make sure all is in place before
> this proposal is put to vote. As usual this TC operates under the
> Non-Assertion Mode of the OASIS IPR Policy, which protects
> anyone implementing the virtio spec.
>
> --
> MST
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
^ permalink raw reply
* Re: [virtio-dev] Re: packed ring layout proposal v3
From: Willem de Bruijn @ 2017-09-12 16:23 UTC (permalink / raw)
To: Jason Wang; +Cc: virtio-dev, virtualization, Michael S. Tsirkin
In-Reply-To: <0f0e1b94-2a46-689c-dbb3-0d578cc8df33@redhat.com>
On Mon, Sep 11, 2017 at 3:47 AM, Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2017年09月10日 13:06, Michael S. Tsirkin wrote:
>>
>> This is an update from v2 version.
>> Changes:
>> - update event suppression mechanism
>> - add wrap counter: DESC_WRAP flag in addition to
>> DESC_DRIVER flag used for validity so device does not have to
>> write out all used descriptors.
>
>
> Do we have benchmark result to show the advantage of DESC_DRIVER over e.g
> avail/used index?
The KVM forum presentation has some numbers.
I'm not sure that synthetic benchmarks will provide much value, as we
understand the trade-off quite well.
The benefit of this model is improved best case performance, by having
a single cacheline read instead of two for the indirect used/avail ring model.
The drawback is worse worst case, as scanning the ring of descriptors
introduces more cacheline misses than scanning the compressed
used/avail ring.
This model is easier to implement in hardware and the common case is
likely close to the best case, so I think it makes sense.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] virtio-iommu version 0.4
From: Auger Eric @ 2017-09-12 17:13 UTC (permalink / raw)
To: Jean-Philippe Brucker, iommu, kvm, virtualization, virtio-dev
Cc: lorenzo.pieralisi, mst, marc.zyngier, will.deacon, robin.murphy,
eric.auger.pro
In-Reply-To: <20170804181927.12148-1-jean-philippe.brucker@arm.com>
Hi jean,
On 04/08/2017 20:19, Jean-Philippe Brucker wrote:
> This is the continuation of my proposal for virtio-iommu, the para-
> virtualized IOMMU. Here is a summary of the changes since last time [1]:
>
> * The virtio-iommu document now resembles an actual specification. It is
> split into a formal description of the virtio device, and implementation
> notes. Please find sources and binaries at [2].
>
> * Added a probe request to describe to the guest different properties that
> do not fit in firmware or in the virtio config space. This is a
> necessary stepping stone for extending the virtio-iommu.
>
> * There is a working Qemu prototype [3], thanks to Eric Auger and Bharat
> Bhushan.
>
> You can find the Linux driver and kvmtool device at [4] and [5]. I
> plan to rework driver and kvmtool device slightly before sending the
> patches.
>
> To understand the virtio-iommu, I advise to first read introduction and
> motivation, then skim through implementation notes and finally look at the
> device specification.
>
> I wasn't sure how to organize the review. For those who prefer to comment
> inline, I attached v0.4 of device-operations.tex and topology.tex+MSI.tex
> to this thread. They are the biggest chunks of the document. But LaTeX
> isn't very pleasant to read, so you can simply send a list of comments in
> relation to section numbers and a few words of context, we'll manage.
>
> ---
> Version numbers 0.1-0.4 are arbitrary. I'm hoping they allow to compare
> more easily differences since the RFC (see [6]), but haven't been made
> public so far. This is the first public posting since initial proposal
> [1], and the following describes all changes.
>
> ## v0.1 ##
>
> Content is the same as the RFC, but formatted to LaTeX. 'make' generates
> one PDF and one HTML document.
>
> ## v0.2 ##
>
> Add introductions, improve topology example and firmware description based
> on feedback and a number of useful discussions.
>
> ## v0.3 ##
>
> Add normative sections (MUST, SHOULD, etc). Clarify some things, tighten
> the device and driver behaviour. Unmap semantics are consolidated; they
> are now closer to VFIO Type1 v2 semantics.
>
> ## v0.4 ##
>
> Introduce PROBE requests. They provide per-endpoint information to the
> driver that couldn't be described otherwise.
>
> For the moment, they allow to handle MSIs on x86 virtual platforms (see
> 3.2). To do that we communicate reserved IOVA regions, that will also be
> useful for describing regions that cannot be mapped for a given endpoint,
> for instance addresses that correspond to a PCI bridge window.
>
> Introducing such a large framework for this tiny feature may seem
> overkill, but it is needed for future extensions of the virtio-iommu and I
> believe it really is worth the effort.
2.6.7
- As I am currently integrating v0.4 in QEMU here are some other comments:
At the moment struct virtio_iommu_req_probe flags is missing in your
header. As such I understood the ACK protocol was not implemented by the
driver in your branch.
- VIRTIO_IOMMU_PROBE_PROPERTY_TYPE_MASK is VIRTIO_IOMMU_T_MASK in your
header too.
2.6.8.2:
- I am really confused about what the device should report as resv
regions depending on the PE nature (VFIO or not VFIO)
In other iommu drivers, the resv regions are populated by the iommu
driver through its get_resv_regions callback. They are usually composed
of an iommu specific MSI region (mapped or bypassed) and non IOMMU
specific (device specific) reserved regions:
iommu_dma_get_resv_regions(). In the case of virtio-iommu driver, those
are the guest reserved regions.
First in the current virtio-iommu driver I don't see the
iommu_dma_get_resv_regions call. Do you agree that the virtio-iommu
driver should compute the non IOMMU specific MSI regions. ie. this is
not the responsability of the virtio-iommu device.
Then why is it more the job of the device to return the guest iommu
specific region rather than the driver itself?
Then I understand this is the responsability of the virtio-iommu device
to gather information about the host resv regions in case of VFIO EP.
Typically the host PCIe host bridge windows cannot be used for IOVA.
Also the host MSI reserved IOVA window cannot be used. Do you agree.
I really think the spec should clarify what exact resv regions the
device should return in case of VFIO device and non VFIO device.
Thanks
Eric
>
> ## Future ##
>
> Other extensions are in preparation. I won't detail them here because v0.4
> already is a lot to digest, but in short, building on top of PROBE:
>
> * First, since the IOMMU is paravirtualized, the device can expose some
> properties of the physical topology to the guest, and let it allocate
> resources more efficiently. For example, when the virtio-iommu manages
> both physical and emulated endpoints, with different underlying IOMMUs,
> we now have a way to describe multiple page and block granularities,
> instead of forcing the guest to use the most restricted one for all
> endpoints. This will most likely be in v0.5.
>
> * Then on top of that, a major improvement will describe hardware
> acceleration features available to the guest. There is what I call "Page
> Table Handover" (or simply, from the host POV, "Nested"), the ability
> for the guest to manipulate its own page tables instead of sending
> MAP/UNMAP requests to the host. This, along with IO Page Fault
> reporting, will also permit SVM virtualization on different platforms.
>
> Thanks,
> Jean
>
> [1] http://www.spinics.net/lists/kvm/msg147990.html
> [2] git://linux-arm.org/virtio-iommu.git branch viommu/v0.4
> http://www.linux-arm.org/git?p=virtio-iommu.git;a=blob;f=dist/v0.4/virtio-iommu-v0.4.pdf
> I reiterate the disclaimers: don't use this document as a reference,
> it's a draft. It's also not an OASIS document yet. It may be riddled
> with mistakes. As this is a working draft, it is unstable and I do not
> guarantee backward compatibility of future versions.
> [3] https://lists.gnu.org/archive/html/qemu-arm/2017-08/msg00004.html
> [4] git://linux-arm.org/linux-jpb.git virtio-iommu/v0.4
> Warning: UAPI headers have changed! They didn't follow the spec,
> please update. (Use branch v0.1, that has the old headers, for the
> Qemu prototype [3])
> [5] git://linux-arm.org/kvmtool-jpb.git virtio-iommu/v0.4
> Warning: command-line has changed! Use --viommu vfio[,opts] and
> --viommu virtio[,opts] to instantiate a device.
> [6] http://www.linux-arm.org/git?p=virtio-iommu.git;a=tree;f=dist/diffs
>
^ permalink raw reply
* [PATCH][V2] drm: qxl: remove pr_info message, stops log spamming
From: Colin King @ 2017-09-12 17:34 UTC (permalink / raw)
To: Dave Airlie, Gerd Hoffmann, David Airlie, virtualization,
dri-devel
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
log with qxl_mmap information messages. The following example code
illustrates this:
int main(void)
{
int fd = open("/dev/dri/card0", O_RDONLY);
if (fd == -1)
err(1, "open failed");
for (;;) {
void *m = mmap(NULL, 4096, PROT_READ,
MAP_SHARED, fd, 0);
if (m != MAP_FAILED)
munmap(m, 4096);
}
}
Stop the spamming by removing the pr_info message. Since the mmap'ing
returns -EINVAL there is no need for the pr_info message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/gpu/drm/qxl/qxl_ttm.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 7ecf8a4b9fe6..0f50c0b25a58 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -123,11 +123,8 @@ int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
struct qxl_device *qdev;
int r;
- if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) {
- pr_info("%s: vma->vm_pgoff (%ld) < DRM_FILE_PAGE_OFFSET\n",
- __func__, vma->vm_pgoff);
+ if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
return -EINVAL;
- }
file_priv = filp->private_data;
qdev = file_priv->minor->dev->dev_private;
--
2.14.1
^ permalink raw reply related
* Re: [Qemu-devel] [RFC] Buffers/caches in VirtIO Balloon driver stats
From: Tomáš Golembiovský @ 2017-09-12 19:23 UTC (permalink / raw)
To: Wei Wang; +Cc: virtio-dev, kvm, Michael S. Tsirkin, qemu-devel, virtualization
In-Reply-To: <20170912162947.130c2df2@fiorina>
Resending. It did not reach virtio-dev the first time.
On Tue, 12 Sep 2017 16:29:47 +0200
Tomáš Golembiovský <tgolembi@redhat.com> wrote:
> On Tue, 29 Aug 2017 20:01:53 +0800
> Wei Wang <wei.w.wang@intel.com> wrote:
>
> > On 08/29/2017 05:57 PM, Stefan Hajnoczi wrote:
> > > On Sun, Aug 27, 2017 at 11:30:33PM +0200, Tomáš Golembiovský wrote:
> > >> Hi,
> > > I have CCed the relevant mailing lists and people most recently involved
> > > in virtio-balloon discussions. Hopefully this will help get the right
> > > people to see your questions.
> > >
> > >> We'd like to include information about reclaimable memory into the
> > >> statistics in VirtiO Balloon driver. Namely, we'd like to include
> > >> counters for bufferes and caches of Linux kernel. The patch itself is
> > >> pretty trivial -- no problem there. But before we do that I'd like to
> > >> get some input from the QEMU community.
> > >>
> > >> 1) Is there any reason not to have the stats there?
> >
> > Could you please share the usages of reclaimable memory via the stats?
>
> I'll go ahead then and start sending patches. What would be the proper
> course of action here? Send patch for the driver first, or send patch
> for QEMU first or send both patches right away?
>
>
> > >>
> > >> 2) Considering the balloon device is multiplatform (Linux, BSD,
> > >> Windows), is there a problem with including buffers/caches? These seem
> > >> to be specific to the Linux virtual memory subsystem. Of course, other
> > >> OSes could just report zeros. Are there some internal stats on those
> > >> OSes that could be filled in? I don't now if such or similar statistic
> > >> are available on BSD. On Windows only SystemCache stat looks like
> > >> something relevant. Anyone familiar with those OSes has any suggestions?
> > >>
> > >>
> >
> > One of the solutions that I'm thinking about is to make virtio
> > platform-ware.
>
> This is not necessary. IIUC the driver does not need to send all the
> stats. We can simply treat those stats as specific to Linux driver and
> other drivers will not send them. Then QEMU will treat them as if zero
> was reported.
>
> >
> > That is, the device by default supports
> > VIRTIO_F_LINUX,
> > VIRTIO_F_WINDOWS,
> > VIRTIO_F_BSD.
> >
> > For the Linux driver, only VIRTIO_F_LINUX is supported, then we can
> > have Linux specific driver implementations under that feature.
>
>
> Since there were no suggestions for similar stats on other OSes I'd say
> we treat the stats for buffers and caches as Linux specific. If there is
> any need to send similar stats for other OSes we will add new stat fields
> (specific for that particular OS).
>
>
> Thanks,
>
> Tomas
>
> --
> Tomáš Golembiovský <tgolembi@redhat.com>
--
Tomáš Golembiovský <tgolembi@redhat.com>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [virtio-dev] Re: packed ring layout proposal v3
From: Jason Wang @ 2017-09-13 1:26 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: virtio-dev, virtualization, Michael S. Tsirkin
In-Reply-To: <CAF=yD-+LtZO=Fcw6Y-v0dnxkmwqW1+CqzopyQEApOjOAszgqMg@mail.gmail.com>
On 2017年09月13日 00:23, Willem de Bruijn wrote:
> On Mon, Sep 11, 2017 at 3:47 AM, Jason Wang <jasowang@redhat.com> wrote:
>>
>> On 2017年09月10日 13:06, Michael S. Tsirkin wrote:
>>> This is an update from v2 version.
>>> Changes:
>>> - update event suppression mechanism
>>> - add wrap counter: DESC_WRAP flag in addition to
>>> DESC_DRIVER flag used for validity so device does not have to
>>> write out all used descriptors.
>>
>> Do we have benchmark result to show the advantage of DESC_DRIVER over e.g
>> avail/used index?
> The KVM forum presentation has some numbers.
Yes. My question may be not accurate. I meant maybe we should benchmark
packed ring layout without DESC_DRIVER but something like queue
tail/head or producer/consumer (or whatever it called). Looks like most
more nic does not use a flag inside descriptor to exam the descriptor
ownership.
>
> I'm not sure that synthetic benchmarks will provide much value, as we
> understand the trade-off quite well.
>
> The benefit of this model is improved best case performance, by having
> a single cacheline read instead of two for the indirect used/avail ring model.
>
> The drawback is worse worst case, as scanning the ring of descriptors
> introduces more cacheline misses than scanning the compressed
> used/avail ring.
Like I've replied, looks like the scanning is not friendly to batching
or prefetching and can cause extra overheads.
>
> This model is easier to implement in hardware and the common case is
> likely close to the best case, so I think it makes sense.
Maybe, but we probably need inputs from hardware vendor guys.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* RE: [RFC] virtio-iommu version 0.4
From: Bharat Bhushan @ 2017-09-13 3:47 UTC (permalink / raw)
To: Auger Eric, Jean-Philippe Brucker,
iommu@lists.linux-foundation.org, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org,
virtio-dev@lists.oasis-open.org
Cc: lorenzo.pieralisi@arm.com, mst@redhat.com, marc.zyngier@arm.com,
will.deacon@arm.com, robin.murphy@arm.com,
eric.auger.pro@gmail.com
In-Reply-To: <072f5a14-baae-57a9-9c5b-b93163c67075@redhat.com>
Hi Eric,
> -----Original Message-----
> From: Auger Eric [mailto:eric.auger@redhat.com]
> Sent: Tuesday, September 12, 2017 10:43 PM
> To: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>;
> iommu@lists.linux-foundation.org; kvm@vger.kernel.org;
> virtualization@lists.linux-foundation.org; virtio-dev@lists.oasis-open.org
> Cc: will.deacon@arm.com; robin.murphy@arm.com;
> lorenzo.pieralisi@arm.com; mst@redhat.com; jasowang@redhat.com;
> marc.zyngier@arm.com; eric.auger.pro@gmail.com; Bharat Bhushan
> <bharat.bhushan@nxp.com>; peterx@redhat.com; kevin.tian@intel.com
> Subject: Re: [RFC] virtio-iommu version 0.4
>
> Hi jean,
>
> On 04/08/2017 20:19, Jean-Philippe Brucker wrote:
> > This is the continuation of my proposal for virtio-iommu, the para-
> > virtualized IOMMU. Here is a summary of the changes since last time [1]:
> >
> > * The virtio-iommu document now resembles an actual specification. It is
> > split into a formal description of the virtio device, and implementation
> > notes. Please find sources and binaries at [2].
> >
> > * Added a probe request to describe to the guest different properties that
> > do not fit in firmware or in the virtio config space. This is a
> > necessary stepping stone for extending the virtio-iommu.
> >
> > * There is a working Qemu prototype [3], thanks to Eric Auger and Bharat
> > Bhushan.
> >
> > You can find the Linux driver and kvmtool device at [4] and [5]. I
> > plan to rework driver and kvmtool device slightly before sending the
> > patches.
> >
> > To understand the virtio-iommu, I advise to first read introduction
> > and motivation, then skim through implementation notes and finally
> > look at the device specification.
> >
> > I wasn't sure how to organize the review. For those who prefer to
> > comment inline, I attached v0.4 of device-operations.tex and
> > topology.tex+MSI.tex to this thread. They are the biggest chunks of
> > the document. But LaTeX isn't very pleasant to read, so you can simply
> > send a list of comments in relation to section numbers and a few words of
> context, we'll manage.
> >
> > ---
> > Version numbers 0.1-0.4 are arbitrary. I'm hoping they allow to
> > compare more easily differences since the RFC (see [6]), but haven't
> > been made public so far. This is the first public posting since
> > initial proposal [1], and the following describes all changes.
> >
> > ## v0.1 ##
> >
> > Content is the same as the RFC, but formatted to LaTeX. 'make'
> > generates one PDF and one HTML document.
> >
> > ## v0.2 ##
> >
> > Add introductions, improve topology example and firmware description
> > based on feedback and a number of useful discussions.
> >
> > ## v0.3 ##
> >
> > Add normative sections (MUST, SHOULD, etc). Clarify some things,
> > tighten the device and driver behaviour. Unmap semantics are
> > consolidated; they are now closer to VFIO Type1 v2 semantics.
> >
> > ## v0.4 ##
> >
> > Introduce PROBE requests. They provide per-endpoint information to the
> > driver that couldn't be described otherwise.
> >
> > For the moment, they allow to handle MSIs on x86 virtual platforms
> > (see 3.2). To do that we communicate reserved IOVA regions, that will
> > also be useful for describing regions that cannot be mapped for a
> > given endpoint, for instance addresses that correspond to a PCI bridge
> window.
> >
> > Introducing such a large framework for this tiny feature may seem
> > overkill, but it is needed for future extensions of the virtio-iommu
> > and I believe it really is worth the effort.
>
> 2.6.7
> - As I am currently integrating v0.4 in QEMU here are some other comments:
> At the moment struct virtio_iommu_req_probe flags is missing in your
> header. As such I understood the ACK protocol was not implemented by the
> driver in your branch.
> - VIRTIO_IOMMU_PROBE_PROPERTY_TYPE_MASK is
> VIRTIO_IOMMU_T_MASK in your header too.
> 2.6.8.2:
> - I am really confused about what the device should report as resv regions
> depending on the PE nature (VFIO or not VFIO)
>
> In other iommu drivers, the resv regions are populated by the iommu driver
> through its get_resv_regions callback. They are usually composed of an
> iommu specific MSI region (mapped or bypassed) and non IOMMU specific
> (device specific) reserved regions:
> iommu_dma_get_resv_regions(). In the case of virtio-iommu driver, those
> are the guest reserved regions.
>
> First in the current virtio-iommu driver I don't see the
> iommu_dma_get_resv_regions call. Do you agree that the virtio-iommu
> driver should compute the non IOMMU specific MSI regions. ie. this is not
> the responsability of the virtio-iommu device.
>
> Then why is it more the job of the device to return the guest iommu specific
> region rather than the driver itself?
>
> Then I understand this is the responsability of the virtio-iommu device to
> gather information about the host resv regions in case of VFIO EP.
> Typically the host PCIe host bridge windows cannot be used for IOVA.
> Also the host MSI reserved IOVA window cannot be used. Do you agree.
>
> I really think the spec should clarify what exact resv regions the device should
> return in case of VFIO device and non VFIO device.
My understanding is that reserved regions are 1) Host reserved regions ( This is applicable for VFIO) 2) Guest MSI reserved region (This is applicable for emulated devices as well)
Does this make sense to have reserved regions per address-space/domain?
Thanks
-Bharat
>
> Thanks
>
> Eric
>
> >
> > ## Future ##
> >
> > Other extensions are in preparation. I won't detail them here because
> > v0.4 already is a lot to digest, but in short, building on top of PROBE:
> >
> > * First, since the IOMMU is paravirtualized, the device can expose some
> > properties of the physical topology to the guest, and let it allocate
> > resources more efficiently. For example, when the virtio-iommu manages
> > both physical and emulated endpoints, with different underlying
> IOMMUs,
> > we now have a way to describe multiple page and block granularities,
> > instead of forcing the guest to use the most restricted one for all
> > endpoints. This will most likely be in v0.5.
> >
> > * Then on top of that, a major improvement will describe hardware
> > acceleration features available to the guest. There is what I call "Page
> > Table Handover" (or simply, from the host POV, "Nested"), the ability
> > for the guest to manipulate its own page tables instead of sending
> > MAP/UNMAP requests to the host. This, along with IO Page Fault
> > reporting, will also permit SVM virtualization on different platforms.
> >
> > Thanks,
> > Jean
> >
> > [1] http://www.spinics.net/lists/kvm/msg147990.html
> > [2] git://linux-arm.org/virtio-iommu.git branch viommu/v0.4
> > http://www.linux-arm.org/git?p=virtio-
> iommu.git;a=blob;f=dist/v0.4/virtio-iommu-v0.4.pdf
> > I reiterate the disclaimers: don't use this document as a reference,
> > it's a draft. It's also not an OASIS document yet. It may be riddled
> > with mistakes. As this is a working draft, it is unstable and I do not
> > guarantee backward compatibility of future versions.
> > [3] https://lists.gnu.org/archive/html/qemu-arm/2017-08/msg00004.html
> > [4] git://linux-arm.org/linux-jpb.git virtio-iommu/v0.4
> > Warning: UAPI headers have changed! They didn't follow the spec,
> > please update. (Use branch v0.1, that has the old headers, for the
> > Qemu prototype [3])
> > [5] git://linux-arm.org/kvmtool-jpb.git virtio-iommu/v0.4
> > Warning: command-line has changed! Use --viommu vfio[,opts] and
> > --viommu virtio[,opts] to instantiate a device.
> > [6]
> > http://www.linux-arm.org/git?p=virtio-iommu.git;a=tree;f=dist/diffs
> >
^ permalink raw reply
* RE: packed ring layout proposal v3
From: Ilya Lesokhin @ 2017-09-14 8:23 UTC (permalink / raw)
To: Michael S. Tsirkin, virtio-dev@lists.oasis-open.org
Cc: virtualization@lists.linux-foundation.org
In-Reply-To: <20160915223915.qjlnlvf2w7u37bu3@redhat.com>
> -----Original Message-----
> From: virtualization-bounces@lists.linux-foundation.org
> [mailto:virtualization-bounces@lists.linux-foundation.org] On Behalf Of
> Michael S. Tsirkin
> Sent: Sunday, September 10, 2017 8:06 AM
> To: virtio-dev@lists.oasis-open.org
> Cc: virtualization@lists.linux-foundation.org
> Subject: packed ring layout proposal v3
>
> This is an update from v2 version.
...
> When driver descriptors are chained in this way, multiple descriptors are
> treated as a part of a single transaction containing an optional write buffer
> followed by an optional read buffer.
> All descriptors in the chain must have the same ID.
>
...
I think you should consider removing the "same ID" requirement.
Assuming out of order execution, how is the driver supposed to re-assign unique IDs to the previously
chained descriptor?
Do you expected driver to copy original IDs somewhere else before the chaining and then restore them after the chain is
executed?
Thanks,
Ilya
^ permalink raw reply
* Call for papers - MOSITS'17 - Moscow, Russia ------ Deadline: October 2
From: Mariana @ 2017-09-14 19:05 UTC (permalink / raw)
To: virtualization
[-- Attachment #1: Type: text/plain, Size: 5767 bytes --]
*** Proceedings published by Springer and indexed by ISI, Scopus, EI-Compendex, DBLP, etc.
---------------------------------------------------------------------------------------------------
MOSITS’17 – The 2017 International Conference on Information Technology Science
Moscow, Russia, 01 – 03 December 2017
https://www.mosits.org/
-------------------------------------------------------------------------------------------------
SCOPE
MOSITS’17 – The 2017 International Conference on Information Technology Science (https://www.mosits.org/), to be held at Moscow, Russia, 01 – 03 December 2017, is an international forum for researchers and practitioners to present and discuss the most recent innovations, trends, results, experiences and concerns in the several perspectives of Information Technology Science.
We are pleased to invite you to submit your papers to MOSITS'17. Papers must be written in English and related with one or more of the Conference Topics (see below). All submissions will be twice «blind» reviewed on the basis of relevance, timeliness, originality, importance and clarity of expression with convincing argumentative.
Accepted and registered Papers will be published in Proceedings by Springer in a book of the AISC series and then indexed by Web of Science, Scopus.
You can see more details on https://www. mosits.org.
TOPICS
Submitted papers should be related with one or more of the main themes proposed for the Conference:
1. Information Technology in Natural Science
• Information Technology in Agriculture & Food Technology
• Information Technology in Biochemistry
• Information Technology in Biology
• Information Technology in Biomedical Sciences
• Information Technology in Chemistry
• Information Technology in Computer Sciences
• Information Technology in Electronics
• Information Technology in Engineering
• Information Technology in Genetics
• Information Technology in Mathematics
• Information Technology in Microbiology
• Information Technology in Medicine
• Information Technology in Nuclear Science
• Information Technology in Pharmacology
• Information Technology in Physics
• Information Technology in Technology & AppliedScience
• Information Technology in Zoology
2. Information Technology in Social Science
• Information Technology in Business & Finance
• Information Technology in Communication
• Information Technology in Criminology & Penology
• Information Technology in Demography
• Information Technology in Economics
• Information Technology in Education
• Information Technology in Law
• Information Technology in Management Science
• Information Technology in Health & Rehabilitation
• Information Technology in Public Administration
3. Information Technology in Art&Humanities
• Information Technology in Archaeology
• Information Technology in Architecture
• Information Technology in Art
• Information Technology in Film
• Information Technology in History
• Information Technology in Humanities
• Information Technology in Linguistic
• Information Technology in Literature
• Information Technology in Religion
• Information Technology in Television & Radio
• Information Technology in Theater
SUBMISSION AND DECISION
You may submit your paper online using address https://www.mosits.org/submission/. Submitted papers should be related with one or more of the Conference topics: Information Technology in Natural Science, Social Science, and Art&Humanities.
In addition, submitted papers (until 8-page limit) must comply with the requested format (download a DOC example) be written in English, must not have been published before, not be under review for any other conference or publication and not include any information leading to the authors’ identification.
All papers will be subjected to a “double-blind review” by at least two Scientific Committee members. The «blind» review means that the authors’ names, affiliations and bibliographic references should not be included in the version for evaluation by the Scientific Committee. This information should only be included in the camera-ready version, saved in Word and/or in PDF format. Based on Scientific Committee evaluation, a paper can be rejected or accepted by the Conference Chairs.
Each accepted paper might be presented in the appropriate thematic session of narrow specialization.
PUBLICATION AND INDEXING
To ensure that an accepted paper will be published, at least one of the authors must be fully registered by the 10th of October 2017, and the paper must comply with the suggested layout and page-limit (until 10 pages). Additionally, all recommended changes must be addressed by the authors before they submit the camera-ready version.
No more than one paper per registration will be published. An extra fee must be paid for publication of additional papers, with a maximum of one additional paper per registration. One registration permits only the participation of one author in the conference.
Accepted and registered Papers will be published in Proceedings by Springer in a book of the AISC series and then indexed by Web of Science, Scopus.
The authors of the best selected papers will be invited to extend them for publication in international journals.
IMPORTANT DATES
Paper Submission Deadline: October 2, 2017
Notification of Acceptance: November 02, 2017
Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: November 10, 2017.
Camera-ready Submission: November 10, 2017
--
MOSITS'17 website: https://www.mosits.org/
-
---
This email has been checked for viruses by AVG.
http://www.avg.com
[-- 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: [Qemu-devel] [RFC] Buffers/caches in VirtIO Balloon driver stats
From: Wei Wang @ 2017-09-15 2:01 UTC (permalink / raw)
To: Tomáš Golembiovský
Cc: virtio-dev, kvm, Michael S. Tsirkin, qemu-devel, virtualization
In-Reply-To: <20170912162947.130c2df2@fiorina>
On 09/12/2017 10:29 PM, Tomáš Golembiovský wrote:
> On Tue, 29 Aug 2017 20:01:53 +0800
> Wei Wang <wei.w.wang@intel.com> wrote:
>
>> On 08/29/2017 05:57 PM, Stefan Hajnoczi wrote:
>>> On Sun, Aug 27, 2017 at 11:30:33PM +0200, Tomáš Golembiovský wrote:
>>>> Hi,
>>> I have CCed the relevant mailing lists and people most recently involved
>>> in virtio-balloon discussions. Hopefully this will help get the right
>>> people to see your questions.
>>>
>>>> We'd like to include information about reclaimable memory into the
>>>> statistics in VirtiO Balloon driver. Namely, we'd like to include
>>>> counters for bufferes and caches of Linux kernel. The patch itself is
>>>> pretty trivial -- no problem there. But before we do that I'd like to
>>>> get some input from the QEMU community.
>>>>
>>>> 1) Is there any reason not to have the stats there?
>> Could you please share the usages of reclaimable memory via the stats?
> I'll go ahead then and start sending patches. What would be the proper
> course of action here? Send patch for the driver first, or send patch
> for QEMU first or send both patches right away?
If you have both ready, I think it would be fine to send them all.
>
>
>>>> 2) Considering the balloon device is multiplatform (Linux, BSD,
>>>> Windows), is there a problem with including buffers/caches? These seem
>>>> to be specific to the Linux virtual memory subsystem. Of course, other
>>>> OSes could just report zeros. Are there some internal stats on those
>>>> OSes that could be filled in? I don't now if such or similar statistic
>>>> are available on BSD. On Windows only SystemCache stat looks like
>>>> something relevant. Anyone familiar with those OSes has any suggestions?
>>>>
>>>>
>> One of the solutions that I'm thinking about is to make virtio
>> platform-ware.
> This is not necessary. IIUC the driver does not need to send all the
> stats. We can simply treat those stats as specific to Linux driver and
> other drivers will not send them. Then QEMU will treat them as if zero
> was reported.
Just had a quick check, I think that should function well too.
QEMU will report -1 for the stats.
Best,
Wei
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Regression in virtio block driver with 4.13.2
From: Laura Abbott @ 2017-09-15 16:54 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang; +Cc: linux-kernel, virtualization
Hi,
Fedora got a bug report on an early version of 4.13.2
https://paste.fedoraproject.org/paste/t-Yx23LN5QwJ7oPZLj3zrg
[ 5.913866] usercopy: kernel memory overwrite attempt detected to
(null) (<null>) (16 bytes)
[ 5.914199] ------------[ cut here ]------------
[ 5.914201] kernel BUG at mm/usercopy.c:72!
[ 5.914279] invalid opcode: 0000 [#1] SMP
[ 5.914293] Modules linked in: ppdev joydev virtio_balloon parport_pc
parport i2c_piix4 virtio_blk virtio_net virtio_console qxl
drm_kms_helper ttm drm virtio_pci virtio_ring serio_raw virtio
ata_generic pata_acpi
[ 5.914353] CPU: 1 PID: 916 Comm: hdparm Not tainted
4.13.2-300.fc27.x86_64 #1
[ 5.914372] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[ 5.914387] task: ffff930a7a67b1c0 task.stack: ffffacef407b8000
[ 5.914411] RIP: 0010:__check_object_size+0x123/0x1b0
[ 5.914425] RSP: 0018:ffffacef407bbc20 EFLAGS: 00010282
[ 5.914440] RAX: 000000000000005a RBX: 0000000000000010 RCX:
0000000000000000
[ 5.914458] RDX: 0000000000000000 RSI: ffff930a7d5ce348 RDI:
ffff930a7d5ce348
[ 5.914476] RBP: ffffacef407bbc40 R08: 00000005a68f139a R09:
0000000000000000
[ 5.914494] R10: 0000000000000001 R11: 0000000000000000 R12:
0000000000000000
[ 5.914512] R13: 0000000000000010 R14: 0000000000000000 R15:
0000000000000010
[ 5.914531] FS: 00007f03e4008740(0000) GS:ffff930a7d400000(0000)
knlGS:0000000000000000
[ 5.914552] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 5.914567] CR2: 00007fff67496fe8 CR3: 0000000079ee2000 CR4:
00000000000006e0
[ 5.914588] Call Trace:
[ 5.914599] sg_io+0xe2/0x400
[ 5.914611] ? __might_fault+0x85/0x90
[ 5.914622] scsi_cmd_ioctl+0x2e0/0x4a0
[ 5.914637] scsi_cmd_blk_ioctl+0x42/0x50
[ 5.914651] virtblk_ioctl+0x56/0x70 [virtio_blk]
[ 5.914666] blkdev_ioctl+0x8f7/0x9b0
[ 5.914679] block_ioctl+0x43/0x50
[ 5.914689] do_vfs_ioctl+0xa6/0x6c0
[ 5.914702] SyS_ioctl+0x79/0x90
[ 5.914714] entry_SYSCALL_64_fastpath+0x1f/0xbe
[ 5.914727] RIP: 0033:0x7f03e3b220d7
[ 5.914737] RSP: 002b:00007fff674992f8 EFLAGS: 00000202 ORIG_RAX:
0000000000000010
[ 5.914758] RAX: ffffffffffffffda RBX: 000000007af2c337 RCX:
00007f03e3b220d7
[ 5.914776] RDX: 00007fff67499320 RSI: 0000000000002285 RDI:
0000000000000003
[ 5.914794] RBP: 00007fff674971b0 R08: 0000000000000000 R09:
0000000000000000
[ 5.914812] R10: 0000000000000003 R11: 0000000000000202 R12:
0000000000000000
[ 5.914830] R13: 00007f03e401dbd8 R14: 00007fff674971d8 R15:
00007f03e4021488
[ 5.914851] Code: 48 0f 45 d1 48 c7 c6 88 75 cb aa 48 c7 c1 0a ab cc
aa 48 0f 45 f1 49 89 d9 49 89 c0 4c 89 f1 48 c7 c7 28 ab cc aa e8 4e 14
e6 ff <0f> 0b f3 c3 48 8b 3d 12 c6 b4 00 48 8b 0d 63 e6 b7 00 be 00 00
[ 5.914938] RIP: __check_object_size+0x123/0x1b0 RSP: ffffacef407bbc20
[ 5.914955] ---[ end trace 7d2ed87f8ebaa2ce ]---
This is from blk_fill_sghdr_rq (block/scsi_ioctl.c:336) and the cryptic
output is saying that req->cmd is NULL. Is this a known issue? I haven't
attempted a bisect yet as I've been at Linux Plumbers.
Thanks,
Laura
Thanks,
Laura
^ permalink raw reply
* Re: Regression in virtio block driver with 4.13.2
From: Christoph Hellwig @ 2017-09-15 17:37 UTC (permalink / raw)
To: Laura Abbott; +Cc: virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <93e65aef-e93d-6a99-854a-f6147f84e3b1@redhat.com>
On Fri, Sep 15, 2017 at 09:54:08AM -0700, Laura Abbott wrote:
> Hi,
>
> Fedora got a bug report on an early version of 4.13.2
> https://paste.fedoraproject.org/paste/t-Yx23LN5QwJ7oPZLj3zrg
Can you check if the issue goes away when you disable
CONFIG_VIRTIO_BLK_SCSI?
^ permalink raw reply
* Re: Regression in virtio block driver with 4.13.2
From: Laura Abbott @ 2017-09-16 23:16 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <20170915173703.GA23073@infradead.org>
On 09/15/2017 10:37 AM, Christoph Hellwig wrote:
> On Fri, Sep 15, 2017 at 09:54:08AM -0700, Laura Abbott wrote:
>> Hi,
>>
>> Fedora got a bug report on an early version of 4.13.2
>> https://paste.fedoraproject.org/paste/t-Yx23LN5QwJ7oPZLj3zrg
>
> Can you check if the issue goes away when you disable
> CONFIG_VIRTIO_BLK_SCSI?
>
Yes, the issue goes away when CONFIG_VIRTIO_BLK_SCSI is
disabled.
Thanks,
Laura
^ permalink raw reply
* Re: Regression in virtio block driver with 4.13.2
From: Christoph Hellwig @ 2017-09-17 23:57 UTC (permalink / raw)
To: Laura Abbott
Cc: Christoph Hellwig, virtualization, linux-kernel,
Michael S. Tsirkin
In-Reply-To: <db314009-f47f-17bc-e2d6-d84936432575@redhat.com>
On Sat, Sep 16, 2017 at 04:16:06PM -0700, Laura Abbott wrote:
> Yes, the issue goes away when CONFIG_VIRTIO_BLK_SCSI is
> disabled.
Ok, so it's probably related to follow ups to the scsi_request split.
That being said, I would highly recommend turning off
CONFIG_VIRTIO_BLK_SCSI in fedora. The feature has caused more trouble
than it helped with, and should never have been added (saying that as
the person who added it). It was never supported with virtio 1.0 devices
and has been disabled in qemu by default for quite a while.
^ permalink raw reply
* [PATCH] vhost: remove unneeded linux/miscdevice.h include
From: Corentin Labbe @ 2017-09-18 16:58 UTC (permalink / raw)
To: mst, jasowang; +Cc: netdev, Corentin Labbe, linux-kernel, kvm, virtualization
drivers/vhost/vhost.c does not use any miscdevice, so this patch
remove this unnecessary inclusion.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/vhost/vhost.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 33ac2b186b85..33ab839696f9 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -16,7 +16,6 @@
#include <linux/uio.h>
#include <linux/mm.h>
#include <linux/mmu_context.h>
-#include <linux/miscdevice.h>
#include <linux/mutex.h>
#include <linux/poll.h>
#include <linux/file.h>
--
2.13.5
^ permalink raw reply related
* [PATCH net-next 1/3] virtio-net: remove unnecessary parameter of virtnet_xdp_xmit()
From: Jason Wang @ 2017-09-19 9:42 UTC (permalink / raw)
To: mst, jasowang, virtualization, netdev, linux-kernel; +Cc: John Fastabend
CC: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/virtio_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 511f833..a0ef4b0 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -373,7 +373,6 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
}
static bool virtnet_xdp_xmit(struct virtnet_info *vi,
- struct receive_queue *rq,
struct xdp_buff *xdp)
{
struct virtio_net_hdr_mrg_rxbuf *hdr;
@@ -542,7 +541,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
delta = orig_data - xdp.data;
break;
case XDP_TX:
- if (unlikely(!virtnet_xdp_xmit(vi, rq, &xdp)))
+ if (unlikely(!virtnet_xdp_xmit(vi, &xdp)))
trace_xdp_exception(vi->dev, xdp_prog, act);
rcu_read_unlock();
goto xdp_xmit;
@@ -677,7 +676,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
}
break;
case XDP_TX:
- if (unlikely(!virtnet_xdp_xmit(vi, rq, &xdp)))
+ if (unlikely(!virtnet_xdp_xmit(vi, &xdp)))
trace_xdp_exception(vi->dev, xdp_prog, act);
ewma_pkt_len_add(&rq->mrg_avg_pkt_len, len);
if (unlikely(xdp_page != page))
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/3] virtio-net: add packet len average only when needed during XDP
From: Jason Wang @ 2017-09-19 9:42 UTC (permalink / raw)
To: mst, jasowang, virtualization, netdev, linux-kernel; +Cc: John Fastabend
In-Reply-To: <1505814163-7315-1-git-send-email-jasowang@redhat.com>
There's no need to add packet len average in the case of XDP_PASS
since it will be done soon after skb is created.
Cc: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/virtio_net.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index a0ef4b0..db5924c 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -656,6 +656,9 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
xdp.data_end = xdp.data + (len - vi->hdr_len);
act = bpf_prog_run_xdp(xdp_prog, &xdp);
+ if (act != XDP_PASS)
+ ewma_pkt_len_add(&rq->mrg_avg_pkt_len, len);
+
switch (act) {
case XDP_PASS:
/* recalculate offset to account for any header
@@ -671,14 +674,12 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
put_page(page);
head_skb = page_to_skb(vi, rq, xdp_page,
offset, len, PAGE_SIZE);
- ewma_pkt_len_add(&rq->mrg_avg_pkt_len, len);
return head_skb;
}
break;
case XDP_TX:
if (unlikely(!virtnet_xdp_xmit(vi, &xdp)))
trace_xdp_exception(vi->dev, xdp_prog, act);
- ewma_pkt_len_add(&rq->mrg_avg_pkt_len, len);
if (unlikely(xdp_page != page))
goto err_xdp;
rcu_read_unlock();
@@ -690,7 +691,6 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
case XDP_DROP:
if (unlikely(xdp_page != page))
__free_pages(xdp_page, 0);
- ewma_pkt_len_add(&rq->mrg_avg_pkt_len, len);
goto err_xdp;
}
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 3/3] virtio-net: support XDP_REDIRECT
From: Jason Wang @ 2017-09-19 9:42 UTC (permalink / raw)
To: mst, jasowang, virtualization, netdev, linux-kernel; +Cc: John Fastabend
In-Reply-To: <1505814163-7315-1-git-send-email-jasowang@redhat.com>
This patch tries to add XDP_REDIRECT for virtio-net. The changes are
not complex as we could use exist XDP_TX helpers for most of the
work. The rest is passing the XDP_TX to NAPI handler for implementing
batching.
Cc: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/virtio_net. | 0
drivers/net/virtio_net.c | 77 ++++++++++++++++++++++++++++++++++++++----------
2 files changed, 62 insertions(+), 15 deletions(-)
create mode 100644 drivers/net/virtio_net.
diff --git a/drivers/net/virtio_net. b/drivers/net/virtio_net.
new file mode 100644
index 0000000..e69de29
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index db5924c..f6c1f13 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -29,6 +29,7 @@
#include <linux/slab.h>
#include <linux/cpu.h>
#include <linux/average.h>
+#include <linux/filter.h>
#include <net/route.h>
static int napi_weight = NAPI_POLL_WEIGHT;
@@ -372,8 +373,20 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
return skb;
}
-static bool virtnet_xdp_xmit(struct virtnet_info *vi,
- struct xdp_buff *xdp)
+static void virtnet_xdp_flush(struct net_device *dev)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ struct send_queue *sq;
+ unsigned int qp;
+
+ qp = vi->curr_queue_pairs - vi->xdp_queue_pairs + smp_processor_id();
+ sq = &vi->sq[qp];
+
+ virtqueue_kick(sq->vq);
+}
+
+static bool __virtnet_xdp_xmit(struct virtnet_info *vi,
+ struct xdp_buff *xdp)
{
struct virtio_net_hdr_mrg_rxbuf *hdr;
unsigned int len;
@@ -407,10 +420,19 @@ static bool virtnet_xdp_xmit(struct virtnet_info *vi,
return false;
}
- virtqueue_kick(sq->vq);
return true;
}
+static int virtnet_xdp_xmit(struct net_device *dev, struct xdp_buff *xdp)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ bool sent = __virtnet_xdp_xmit(vi, xdp);
+
+ if (!sent)
+ return -ENOSPC;
+ return 0;
+}
+
static unsigned int virtnet_get_headroom(struct virtnet_info *vi)
{
return vi->xdp_queue_pairs ? VIRTIO_XDP_HEADROOM : 0;
@@ -483,7 +505,8 @@ static struct sk_buff *receive_small(struct net_device *dev,
struct virtnet_info *vi,
struct receive_queue *rq,
void *buf, void *ctx,
- unsigned int len)
+ unsigned int len,
+ bool *xdp_xmit)
{
struct sk_buff *skb;
struct bpf_prog *xdp_prog;
@@ -493,7 +516,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
unsigned int buflen = SKB_DATA_ALIGN(GOOD_PACKET_LEN + headroom) +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
struct page *page = virt_to_head_page(buf);
- unsigned int delta = 0;
+ unsigned int delta = 0, err;
struct page *xdp_page;
len -= vi->hdr_len;
@@ -541,8 +564,16 @@ static struct sk_buff *receive_small(struct net_device *dev,
delta = orig_data - xdp.data;
break;
case XDP_TX:
- if (unlikely(!virtnet_xdp_xmit(vi, &xdp)))
+ if (unlikely(!__virtnet_xdp_xmit(vi, &xdp)))
trace_xdp_exception(vi->dev, xdp_prog, act);
+ else
+ *xdp_xmit = true;
+ rcu_read_unlock();
+ goto xdp_xmit;
+ case XDP_REDIRECT:
+ err = xdp_do_redirect(dev, &xdp, xdp_prog);
+ if (!err)
+ *xdp_xmit = true;
rcu_read_unlock();
goto xdp_xmit;
default:
@@ -603,7 +634,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
struct receive_queue *rq,
void *buf,
void *ctx,
- unsigned int len)
+ unsigned int len,
+ bool *xdp_xmit)
{
struct virtio_net_hdr_mrg_rxbuf *hdr = buf;
u16 num_buf = virtio16_to_cpu(vi->vdev, hdr->num_buffers);
@@ -613,6 +645,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
struct bpf_prog *xdp_prog;
unsigned int truesize;
unsigned int headroom = mergeable_ctx_to_headroom(ctx);
+ int err;
head_skb = NULL;
@@ -678,12 +711,20 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
}
break;
case XDP_TX:
- if (unlikely(!virtnet_xdp_xmit(vi, &xdp)))
+ if (unlikely(!__virtnet_xdp_xmit(vi, &xdp)))
trace_xdp_exception(vi->dev, xdp_prog, act);
+ else
+ *xdp_xmit = true;
if (unlikely(xdp_page != page))
goto err_xdp;
rcu_read_unlock();
goto xdp_xmit;
+ case XDP_REDIRECT:
+ err = xdp_do_redirect(dev, &xdp, xdp_prog);
+ if (err)
+ *xdp_xmit = true;
+ rcu_read_unlock();
+ goto xdp_xmit;
default:
bpf_warn_invalid_xdp_action(act);
case XDP_ABORTED:
@@ -788,7 +829,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
}
static int receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
- void *buf, unsigned int len, void **ctx)
+ void *buf, unsigned int len, void **ctx, bool *xdp_xmit)
{
struct net_device *dev = vi->dev;
struct sk_buff *skb;
@@ -809,11 +850,11 @@ static int receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
}
if (vi->mergeable_rx_bufs)
- skb = receive_mergeable(dev, vi, rq, buf, ctx, len);
+ skb = receive_mergeable(dev, vi, rq, buf, ctx, len, xdp_xmit);
else if (vi->big_packets)
skb = receive_big(dev, vi, rq, buf, len);
else
- skb = receive_small(dev, vi, rq, buf, ctx, len);
+ skb = receive_small(dev, vi, rq, buf, ctx, len, xdp_xmit);
if (unlikely(!skb))
return 0;
@@ -1071,7 +1112,7 @@ static void refill_work(struct work_struct *work)
}
}
-static int virtnet_receive(struct receive_queue *rq, int budget)
+static int virtnet_receive(struct receive_queue *rq, int budget, bool *xdp_xmit)
{
struct virtnet_info *vi = rq->vq->vdev->priv;
unsigned int len, received = 0, bytes = 0;
@@ -1083,13 +1124,13 @@ static int virtnet_receive(struct receive_queue *rq, int budget)
while (received < budget &&
(buf = virtqueue_get_buf_ctx(rq->vq, &len, &ctx))) {
- bytes += receive_buf(vi, rq, buf, len, ctx);
+ bytes += receive_buf(vi, rq, buf, len, ctx, xdp_xmit);
received++;
}
} else {
while (received < budget &&
(buf = virtqueue_get_buf(rq->vq, &len)) != NULL) {
- bytes += receive_buf(vi, rq, buf, len, NULL);
+ bytes += receive_buf(vi, rq, buf, len, NULL, xdp_xmit);
received++;
}
}
@@ -1161,15 +1202,19 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
struct receive_queue *rq =
container_of(napi, struct receive_queue, napi);
unsigned int received;
+ bool xdp_xmit = false;
virtnet_poll_cleantx(rq);
- received = virtnet_receive(rq, budget);
+ received = virtnet_receive(rq, budget, &xdp_xmit);
/* Out of packets? */
if (received < budget)
virtqueue_napi_complete(napi, rq->vq, received);
+ if (xdp_xmit)
+ xdp_do_flush_map();
+
return received;
}
@@ -2069,6 +2114,8 @@ static const struct net_device_ops virtnet_netdev = {
.ndo_poll_controller = virtnet_netpoll,
#endif
.ndo_xdp = virtnet_xdp,
+ .ndo_xdp_xmit = virtnet_xdp_xmit,
+ .ndo_xdp_flush = virtnet_xdp_flush,
.ndo_features_check = passthru_features_check,
};
--
2.7.4
^ permalink raw reply related
* Re: [RFC] virtio-iommu version 0.4
From: Jean-Philippe Brucker @ 2017-09-19 10:47 UTC (permalink / raw)
To: Auger Eric, iommu@lists.linux-foundation.org, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org,
virtio-dev@lists.oasis-open.org
Cc: Lorenzo Pieralisi, mst@redhat.com, Marc Zyngier, Will Deacon,
Robin Murphy, eric.auger.pro@gmail.com
In-Reply-To: <072f5a14-baae-57a9-9c5b-b93163c67075@redhat.com>
Hi Eric,
On 12/09/17 18:13, Auger Eric wrote:
> 2.6.7
> - As I am currently integrating v0.4 in QEMU here are some other comments:
> At the moment struct virtio_iommu_req_probe flags is missing in your
> header. As such I understood the ACK protocol was not implemented by the
> driver in your branch.
Uh indeed. And yet I could swear I've written that code... somewhere. I
will add it to the batch of v0.5 changes, it shouldn't be too invasive.
> - VIRTIO_IOMMU_PROBE_PROPERTY_TYPE_MASK is VIRTIO_IOMMU_T_MASK in your
> header too.
Yes, keeping VIRTIO_IOMMU_PROBE_PROPERTY_TYPE_MASK is probably best
(though it is a mouthful).
> 2.6.8.2:
> - I am really confused about what the device should report as resv
> regions depending on the PE nature (VFIO or not VFIO)
>
> In other iommu drivers, the resv regions are populated by the iommu
> driver through its get_resv_regions callback. They are usually composed
> of an iommu specific MSI region (mapped or bypassed) and non IOMMU
> specific (device specific) reserved regions:
> iommu_dma_get_resv_regions(). In the case of virtio-iommu driver, those
> are the guest reserved regions.
>
> First in the current virtio-iommu driver I don't see the
> iommu_dma_get_resv_regions call. Do you agree that the virtio-iommu
> driver should compute the non IOMMU specific MSI regions. ie. this is
> not the responsability of the virtio-iommu device.
For SW_MSI, certainly. The driver allocates a fixed IOVA region for
mapping the MSI doorbell. But the driver has to know whether the doorbell
region is translated or bypassed.
> Then why is it more the job of the device to return the guest iommu
> specific region rather than the driver itself?
The MSI region is architectural on x86 IOMMUs, but
implementation-defined on virtio-iommu. It depends which platform the host
is emulating. In Linux, x86 IOMMU drivers register the bypass region
because there always is an IOAPIC on the other end, with a fixed MSI
address. But virtio-iommu may be either behind a GIC, an APIC or some
other IRQ chip.
The driver *could* go over all the irqchips/platforms it knows and try to
guess if there is a fixed doorbell or if it needs to reserve an IOVA for
them, but it would look horrible. I much prefer having a well-defined way
of doing this, so a description from the device.
> Then I understand this is the responsability of the virtio-iommu device
> to gather information about the host resv regions in case of VFIO EP.
> Typically the host PCIe host bridge windows cannot be used for IOVA.
> Also the host MSI reserved IOVA window cannot be used. Do you agree.
Yes, all regions reported in sysfs reserved_regions in the host would be
reported as RESV_T_RESERVED by virtio-iommu.
> I really think the spec should clarify what exact resv regions the
> device should return in case of VFIO device and non VFIO device.
Agreed. I will add something about RESV_T_RESERVED with the PCI bridge
example in Implementation Notes. Do you think the MSI examples at the end
need improvement as well? I can try to explain that RESV_MSI regions in
virtio-iommu are only those of the emulated platform, not the HW or SW MSI
regions from the host.
Thanks,
Jean
^ permalink raw reply
* Re: Regression in virtio block driver with 4.13.2
From: Laura Abbott @ 2017-09-20 0:15 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <20170917235731.GA31789@infradead.org>
On 09/17/2017 04:57 PM, Christoph Hellwig wrote:
> On Sat, Sep 16, 2017 at 04:16:06PM -0700, Laura Abbott wrote:
>> Yes, the issue goes away when CONFIG_VIRTIO_BLK_SCSI is
>> disabled.
>
> Ok, so it's probably related to follow ups to the scsi_request split.
>
> That being said, I would highly recommend turning off
> CONFIG_VIRTIO_BLK_SCSI in fedora. The feature has caused more trouble
> than it helped with, and should never have been added (saying that as
> the person who added it). It was never supported with virtio 1.0 devices
> and has been disabled in qemu by default for quite a while.
>
Thanks for the pointer, I went and turned it off on our 4.13 based
kernels.
Laura
^ permalink raw reply
* RE: [virtio-dev] packed ring layout proposal v3
From: Liang, Cunming @ 2017-09-20 9:11 UTC (permalink / raw)
To: Michael S. Tsirkin, virtio-dev@lists.oasis-open.org
Cc: virtualization@lists.linux-foundation.org
In-Reply-To: <20160915223915.qjlnlvf2w7u37bu3@redhat.com>
Hi Michael,
> -----Original Message-----
> From: virtio-dev@lists.oasis-open.org [mailto:virtio-dev@lists.oasis-open.org]
> On Behalf Of Michael S. Tsirkin
> Sent: Sunday, September 10, 2017 1:06 PM
> To: virtio-dev@lists.oasis-open.org
> Cc: virtualization@lists.linux-foundation.org
> Subject: [virtio-dev] packed ring layout proposal v3
>
[...]
> * Descriptor ring:
>
> Driver writes descriptors with unique index values and DESC_DRIVER set in
> flags.
> Descriptors are written in a ring order: from start to end of ring, wrapping
> around to the beginning.
> Device writes used descriptors with correct len, index, and DESC_HW clear.
> Again descriptors are written in ring order. This might not be the same order
> of driver descriptors, and not all descriptors have to be written out.
>
> Driver and device are expected to maintain (internally) a wrap-around bit,
> starting at 0 and changing value each time they start writing out descriptors
> at the beginning of the ring. This bit is passed as DESC_WRAP bit in the flags
> field.
One simple question there, trying to understand the usage of DESC_WRAP flag.
DESC_WRAP bit is a new flag since v2. It's used to address 'non power-of-2 ring sizes' mentioned in v2?
Being confused by the statement of wrap-around bit here, it's an internal wrap-around counter represented by single bit (0/1)?
DESC_WRAP can appear on any descriptor entry in the ring, why it highlights changing value at the beginning of the ring?
>
> Flags are always set/cleared last.
>
> Note that driver can write descriptors out in any order, but device will not
> execute descriptor X+1 until descriptor X has been read as valid.
>
> Driver operation:
>
[...]
>
> DESC_WRAP - device uses this field to detect descriptor change by driver.
Device uses this field to detect change of wrap-around boundary by driver?
[...]
>
> Device operation (using descriptors):
>
[...]
>
> DESC_WRAP - driver uses this field to detect descriptor change by device.
Driver uses this field to detect change of wrap-around boundary by device?
By using this, driver doesn't need to maintain any internal wrap-around count, but being aware of wrap-around by DESC_WRAP flag.
Thanks,
Steve
>
[...]
>
> ---
>
> Note: should this proposal be accepted and approved, one or more
> claims disclosed to the TC admin and listed on the Virtio TC
> IPR page https://www.oasis-open.org/committees/virtio/ipr.php
> might become Essential Claims.
> Note: the page above is unfortunately out of date and out of
> my hands. I'm in the process of updating ipr disclosures
> in github instead. Will make sure all is in place before
> this proposal is put to vote. As usual this TC operates under the
> Non-Assertion Mode of the OASIS IPR Policy, which protects
> anyone implementing the virtio spec.
>
> --
> MST
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply
* Re: [RFC] virtio-iommu version 0.4
From: Auger Eric @ 2017-09-20 9:37 UTC (permalink / raw)
To: Jean-Philippe Brucker, iommu@lists.linux-foundation.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
virtio-dev@lists.oasis-open.org
Cc: Lorenzo Pieralisi, mst@redhat.com, Marc Zyngier, Will Deacon,
Robin Murphy, eric.auger.pro@gmail.com
In-Reply-To: <4543e6dc-0f36-11ad-784a-d7c07399d10f@arm.com>
Hi Jean,
On 19/09/2017 12:47, Jean-Philippe Brucker wrote:
> Hi Eric,
>
> On 12/09/17 18:13, Auger Eric wrote:
>> 2.6.7
>> - As I am currently integrating v0.4 in QEMU here are some other comments:
>> At the moment struct virtio_iommu_req_probe flags is missing in your
>> header. As such I understood the ACK protocol was not implemented by the
>> driver in your branch.
>
> Uh indeed. And yet I could swear I've written that code... somewhere. I
> will add it to the batch of v0.5 changes, it shouldn't be too invasive.
>
>> - VIRTIO_IOMMU_PROBE_PROPERTY_TYPE_MASK is VIRTIO_IOMMU_T_MASK in your
>> header too.
>
> Yes, keeping VIRTIO_IOMMU_PROBE_PROPERTY_TYPE_MASK is probably best
> (though it is a mouthful).
>
>> 2.6.8.2:
>> - I am really confused about what the device should report as resv
>> regions depending on the PE nature (VFIO or not VFIO)
>>
>> In other iommu drivers, the resv regions are populated by the iommu
>> driver through its get_resv_regions callback. They are usually composed
>> of an iommu specific MSI region (mapped or bypassed) and non IOMMU
>> specific (device specific) reserved regions:
>> iommu_dma_get_resv_regions(). In the case of virtio-iommu driver, those
>> are the guest reserved regions.
>>
>> First in the current virtio-iommu driver I don't see the
>> iommu_dma_get_resv_regions call. Do you agree that the virtio-iommu
>> driver should compute the non IOMMU specific MSI regions ie. this is
>> not the responsability of the virtio-iommu device.
>
> For SW_MSI, certainly. The driver allocates a fixed IOVA region for
> mapping the MSI doorbell. But the driver has to know whether the doorbell
> region is translated or bypassed.
Sorry I was talking about *non* IOMMU specific MSI regions, typically
the regions corresponding to guest PCI host bridge windows. This is
normally computed in the iommu driver and I didn't that that in the
existing virtio-iommu driver.
>
>> Then why is it more the job of the device to return the guest iommu
>> specific region rather than the driver itself?
>
> The MSI region is architectural on x86 IOMMUs, but
> implementation-defined on virtio-iommu. It depends which platform the host
> is emulating. In Linux, x86 IOMMU drivers register the bypass region
> because there always is an IOAPIC on the other end, with a fixed MSI
> address. But virtio-iommu may be either behind a GIC, an APIC or some
> other IRQ chip.
>
> The driver *could* go over all the irqchips/platforms it knows and try to
> guess if there is a fixed doorbell or if it needs to reserve an IOVA for
> them, but it would look horrible. I much prefer having a well-defined way
> of doing this, so a description from the device.
This means I must have target specific code in the virtio-iommu device
which is unusual, right? I was initially thinking you could handle that
on the driver side using a config set for ARM|ARM64. But on the other
hand you should communicate the info to the device ...
>
>> Then I understand this is the responsability of the virtio-iommu device
>> to gather information about the host resv regions in case of VFIO EP.
>> Typically the host PCIe host bridge windows cannot be used for IOVA.
>> Also the host MSI reserved IOVA window cannot be used. Do you agree.
>
> Yes, all regions reported in sysfs reserved_regions in the host would be
> reported as RESV_T_RESERVED by virtio-iommu.
So to summarize if the probe request is sent to an emulated device, we
should return the target specific MSI window. We can't and don't return
the non IOMMU specific guest reserved windows.
For a VFIO device, we would return all reserved regions of the group the
device belongs to. Is that correct?
>
>> I really think the spec should clarify what exact resv regions the
>> device should return in case of VFIO device and non VFIO device.
>
> Agreed. I will add something about RESV_T_RESERVED with the PCI bridge
> example in Implementation Notes. Do you think the MSI examples at the end
> need improvement as well? I can try to explain that RESV_MSI regions in
> virtio-iommu are only those of the emulated platform, not the HW or SW MSI
> regions from the host.
I think I would expect an explanation detailing returned reserved
regions for pure emulated devices and HW/VFIO devices.
Another unrelated remark:
- you should add a permission violation error.
- wrt the probe request ACK protocol, this looks pretty heavy as both
the driver and the device need to parse the req_probe buffer. The device
need to fill in the output buffer and then read the same info on the
input buffer. Couldn't we imagine something simpler?
Thanks
Eric
>
> Thanks,
> Jean
>
^ 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