Rusty Russell writes:
> Jamie Lokier writes:
>
>> Rusty Russell wrote:
>>> I don't think it'll be that bad; reset clears the device to unknown,
>>> bar0 moves it from unknown->legacy mode, bar1/2/3 changes it from
>>> unknown->modern m
"Michael S. Tsirkin" writes:
> On Wed, Oct 10, 2012 at 08:36:12AM -0500, Anthony Liguori wrote:
>> Rusty Russell writes:
>>
>> > Gerd Hoffmann writes:
>> >> So how about this:
>> >>
>> >> (1) Add a vendor specific pci cap
Paolo Bonzini writes:
> Il 09/10/2012 06:59, Rusty Russell ha scritto:
>> Paolo Bonzini writes:
>>> Il 05/10/2012 07:43, Rusty Russell ha scritto:
>>>> That's good. But virtio_blk's scsi command is insoluble AFAICT. As I
>>>> said to Anth
Cornelia Huck writes:
> On Thu, 27 Sep 2012 09:59:33 +0930
> Rusty Russell wrote:
>> 3) Various clarifications, formalizations and cleanups to the spec text,
>>and possibly elimination of old deprecated features.
>>
>> 4) The only significant change
Gerd Hoffmann writes:
> So how about this:
>
> (1) Add a vendor specific pci capability for new-style virtio.
> Specifies the pci bar used for new-style virtio registers.
> Guests can use it to figure whenever new-style virtio is
> supported and to map the correct bar (which will proba
Anthony Liguori writes:
> Rusty Russell writes:
>
>> Anthony Liguori writes:
>>> We'll never remove legacy so we shouldn't plan on it. There are
>>> literally hundreds of thousands of VMs out there with the current virtio
>>> drivers instal
Jamie Lokier writes:
> Rusty Russell wrote:
>> I don't think it'll be that bad; reset clears the device to unknown,
>> bar0 moves it from unknown->legacy mode, bar1/2/3 changes it from
>> unknown->modern mode, and anything else is bad (I prefer being stri
Paolo Bonzini writes:
> Il 05/10/2012 07:43, Rusty Russell ha scritto:
>> That's good. But virtio_blk's scsi command is insoluble AFAICT. As I
>> said to Anthony, the best rules are "always" and "never", so I'd really
>> rather not have
Anthony Liguori writes:
> We'll never remove legacy so we shouldn't plan on it. There are
> literally hundreds of thousands of VMs out there with the current virtio
> drivers installed in them. We'll be supporting them for a very, very
> long time :-)
You will be supporting this for qemu on x86
Anthony Liguori writes:
> Gerd Hoffmann writes:
>
>> Hi,
>>
So we could have for virtio something like this:
Capabilities: [??] virtio-regs:
legacy: BAR=0 offset=0
virtio-pci: BAR=1 offset=1000
virtio-cfg: BAR
(Topic updated, cc's trimmed).
Anthony Liguori writes:
> Rusty Russell writes:
>> 4) The only significant change to the spec is that we use PCI
>>capabilities, so we can have infinite feature bits.
>>(see
>> http://lists.linuxfoundation.org/pipermail/vir
Paolo Bonzini writes:
> Il 04/10/2012 14:51, Rusty Russell ha scritto:
>> Paolo Bonzini writes:
>>
>>> Il 04/10/2012 02:11, Rusty Russell ha scritto:
>>>>>> There's a reason I haven't done this. I really, really dislike "my
>>
ichael S. Tsirkin (3):
virtio-balloon: dependency fix
virtio: support reserved vqs
virtio: don't crash when device is buggy
Peter Senna Tschudin (1):
drivers/virtio/virtio_pci.c: fix error return code
Rusty Russell (4):
virtio_balloon: not EXPERIMENTAL any more.
Paolo Bonzini writes:
> Il 04/10/2012 02:11, Rusty Russell ha scritto:
>> > > There's a reason I haven't done this. I really, really dislike "my
>> > > implemention isn't broken" feature bits. We could have an infinite
>> > > numb
are always a mistake, but I can't blame anyone
else for my lack of attention :(
Here's the spec change:
commit 7e74459bb966ccbaad9e4bf361d1178b7f400b79
Author: Rusty Russell
Date: Thu Oct 4 17:11:27 2012 +0930
No longer assume framing is independent of messages. *sniff*
Signed-off-by: R
Anthony Liguori writes:
> Rusty Russell writes:
>
>> "Michael S. Tsirkin" writes:
>>
>> There's a reason I haven't done this. I really, really dislike "my
>> implemention isn't broken" feature bits. We could have an infinite
Anthony Liguori writes:
> Rusty Russell writes:
>
>> "Michael S. Tsirkin" writes:
>>
>>> Thinking about Sasha's patches, we can reduce ring usage
>>> for virtio net small packets dramatically if we put
>>> virtio net header inline wi
Paolo Bonzini writes:
> Il 03/10/2012 08:44, Rusty Russell ha scritto:
>> There's a reason I haven't done this. I really, really dislike "my
>> implemention isn't broken" feature bits. We could have an infinite
>> number of them, for each bug
"Michael S. Tsirkin" writes:
> Capacity math on ring full is wrong: we are
> looking at num_sg but that might be optimistic
> because of indirect buffer use.
>
> The implementation also penalizes fast path
> with extra memory accesses for the benefit of
> ring full condition handling which is slow
Rusty Russell writes:
> "Michael S. Tsirkin" writes:
>
>> Thinking about Sasha's patches, we can reduce ring usage
>> for virtio net small packets dramatically if we put
>> virtio net header inline with the data.
>> This can be done for free in case
Building the latest git now...
Cheers,
Rusty.
Subject: virtio: CONFIG_VIRTIO_DEVICE_TORTURE
Virtio devices are not supposed to depend on the framing of the scatter-gather
lists, but various implementations did. Safeguard this in future by adding
an option to deliberately create perverse de
Hi Stephen,
Please remove my quilt tree
http://ozlabs.org/~rusty/kernel/rr-latest/ from linux-next, and use my
git trees from now on:
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git
Branches:
modules-next
virtio-next
For others: beware that these will rebase
Asias He writes:
>> I forgot about the cool hack which MST put in to defer event updates
>> using disable_cb/enable_cb.
>
> Hmm, are you talking about virtqueue_enable_cb_delayed()?
Just the fact that virtqueue_disable_cb() prevents updates of
used_index, and then we do the update in virtqueue_en
Sjur BRENDELAND writes:
>> This allocates one redundant sg entry when nrbuf > 0,
>> but I think it is OK. (just a comment)
>
> I did this on purpose for the sake of simplicity, but I can
> change this to something like:
>alloc_size = sizeof(*buf) + sizeof(buf->sg) * max(nrbufs - 1, 1);
Th
Hi all,
I've had several requests for a more formal approach to the
virtio draft spec, and (after some soul-searching) I'd like to try that.
The proposal is to use OASIS as the standards body, as it's
fairly light-weight as these things go. For me this means paperwork and
setting
Asias He writes:
> On 09/25/2012 10:36 AM, Asias He wrote:
>> This reduces unnecessary interrupts that host could send to guest while
>> guest is in the progress of irq handling.
>>
>> If one vcpu is handling the irq, while another interrupt comes, in
>> handle_edge_irq(), the guest will mask th
sjur.brandel...@stericsson.com writes:
> From: Sjur Brændeland
>
> Add a simple serial connection driver called
> VIRTIO_ID_RPROC_SERIAL (11) for communicating with a
> remote processor in an asymmetric multi-processing
> configuration.
>
...
> static struct port_buffer *alloc_buf(struct virtqueu
Pawel Moll writes:
> On Tue, 2012-09-25 at 01:11 +0100, Rusty Russell wrote:
>> > Would you be so kind and consider getting those two small fixes into
>> > 3.7 merge? All credits go to Brian, all shame on me :-)
>>
>> Should these also be cc'd to sta...@k
Amit Shah writes:
> On (Mon) 24 Sep 2012 [23:50:01], Sjur BRENDELAND wrote:
>> Hi Amit,
>>
>> > I'm sorry for not being able to look at this earlier.
>>
>> No worries. I'll try to respin and retest this patch by tomorrow.
>> If you by any chance could find time to review so could make it in tim
Pawel Moll writes:
> Hi Rusty,
>
> Would you be so kind and consider getting those two small fixes into
> 3.7 merge? All credits go to Brian, all shame on me :-)
Should these also be cc'd to sta...@kernel.org?
Cheers,
Rusty.
___
Virtualization mailing
sjur.brandel...@stericsson.com writes:
> From: Sjur Brændeland
>
> Add a simple serial connection driver called
> VIRTIO_ID_RPROC_SERIAL (0xB) for communicating with a
> remote processor in an asymmetric multi-processing
> configuration.
>
> This implementation reuses the existing virtio_console
Tom Herbert writes:
> On Tue, Sep 11, 2012 at 10:49 PM, Rusty Russell wrote:
>> Perhaps Tom can explain how we avoid out-of-order receive for the
>> accelerated RFS case? It's not clear to me, but we need to be able to
>> do that for virtio-net if it implements acceler
"Michael S. Tsirkin" writes:
> On Mon, Sep 17, 2012 at 01:57:17PM +0930, Rusty Russell wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > Because of a sanity check in virtio_dev_remove, a buggy device can crash
>> > kernel. And in case of rpro
Laszlo Ersek writes:
> Hi,
>
> the vring_size() formula in section 2.3 seems to miss
>
> (a) "vring_avail.used_event" in the first ALIGN(), and
>
> (b) "vring_used.flags", "vring_used.idx", "vring_used.avail_event" in
> the second ALIGN().
>
> vring_size() in Appendix A fixes (b) (no rounding up t
Andrew Morton writes:
> On Mon, 17 Sep 2012 13:38:15 -0300
> Rafael Aquini wrote:
>> Results for STRESS-HIGHALLOC benchmark, from Mel Gorman's mmtests suite,
>> running on a 4gB RAM KVM guest which was ballooning 1gB RAM in 256mB chunks,
>> at every minute (inflating/deflating), while test was ru
Peter Senna Tschudin writes:
> From: Peter Senna Tschudin
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
Thanks!
Applied,
Rusty.
___
Virtualization mailing list
Virtualization@lists.linux-found
"Michael S. Tsirkin" writes:
> Because of a sanity check in virtio_dev_remove, a buggy device can crash
> kernel. And in case of rproc it's userspace so it's not a good idea.
> We are unloading a driver so how bad can it be?
> Be less aggressive in handling this error: if it's a driver bug,
> wa
Thomas Lendacky writes:
> I ran some TCP_RR and TCP_STREAM sessions, both host-to-guest and
> guest-to-host, with a form of the histogram patch applied against a
> RHEL6.3 kernel. The histogram values were reset after each test.
Hey, thanks! This is exactly what I wanted to see...
> 60 session
sjur.brandel...@stericsson.com writes:
> I actually like this new approach better.
> It solves the issues Michael has pointed out, and we don't have to
> think through side effects of weired combination of feature bits.
Agreed.
Just one thing, should it depend on CONFIG_REMOTEPROC? And have
OMAP
Jason Wang writes:
> On 09/10/2012 02:33 PM, Michael S. Tsirkin wrote:
>> A final addition: what you suggest above would be
>> "TX follows RX", right?
BTW, yes. But it's a weird way to express what the nic is doing.
>> It is in anticipation of something like that, that I made
>> steering progra
Mike Waychison writes:
> On Mon, Sep 10, 2012 at 3:59 PM, Michael S. Tsirkin wrote:
>> On Mon, Sep 10, 2012 at 01:37:06PM -0400, Mike Waychison wrote:
>>> On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin wrote:
>>> > On Tue, Jun 26, 2012 at 01:32:58PM -0700, Frank Swiderski wrote:
>>> >> This
"Michael S. Tsirkin" writes:
> We have several options:
> 1. No memory overcommit feature. This is always the case ATM!
> 2. Do not hot-plug assigned device.
> 3. Hot-unplug assigned device.
> 4. Some assigned devices can be able to handle memory errors
>e.g. using ATS. Limit hotplug to these.
"Michael S. Tsirkin" writes:
>> virtio: don't crash when device is buggy
>>
>> Because of a sanity check in virtio_dev_remove, a buggy device can crash
>> kernel. And in case of rproc it's userspace so it's not a good idea.
>> We are unloading a driver so how bad can it be?
>> Be less aggressive
"Michael S. Tsirkin" writes:
> In other words RPS is a hack to speed up networking on cheapo
> hardware, this is one of the reasons it is off by default.
> Good hardware has multiple receive queues.
> We can implement a good one so we do not need RPS.
>
> Also not all guest OS-es support RPS.
>
>
sjur.brandel...@stericsson.com writes:
> From: Sjur Brændeland
>
> Add feature VIRTIO_CONSOLE_F_DMA_MEM. If the architecture has
> DMA support and this feature bit is set, the virtio data buffers
> will be allocated from DMA memory. If the device requests
> the feature VIRTIO_CONSOLE_F_DMA_MEM, b
"Michael S. Tsirkin" writes:
> On Sat, Sep 08, 2012 at 02:36:00PM +0930, Rusty Russell wrote:
>> "Michael S. Tsirkin" writes:
>> > On Fri, Sep 07, 2012 at 04:09:50PM +0930, Rusty Russell wrote:
>> >> > So it looks like a bug: we sh
OK, I read the spec (pasted below for easy of reading), but I'm still
confused over how this will work.
I thought normal net drivers have the hardware provide an rxhash for
each packet, and we map that to CPU to queue the packet on[1]. We hope
that the receiving process migrates to that CPU, so x
Amit Shah writes:
> On (Sat) 01 Sep 2012 [23:49:37], Alexey Khoroshilov wrote:
>> If register_virtio_driver() fails, virtio-ports class is not destroyed.
>> The patch adds error handling of register_virtio_driver().
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
>>
>> Signe
"Michael S. Tsirkin" writes:
> On Fri, Sep 07, 2012 at 04:09:50PM +0930, Rusty Russell wrote:
>> > So it looks like a bug: we should teach driver to tell host first on leak?
>> > Yan, Vadim, can you comment please?
>> >
>> > Also if true, loo
"Michael S. Tsirkin" writes:
> On Fri, Sep 07, 2012 at 09:15:46AM +0930, Rusty Russell wrote:
>> Paolo Bonzini writes:
>> > Instead, VIRTIO_NET_F_HOST_MUST_SEND_GARP would be a "negative" feature:
>> > if set, the host _may not_ rely
Kent Overstreet writes:
> On Fri, Sep 07, 2012 at 09:10:25AM +0930, Rusty Russell wrote:
>> Kent Overstreet writes:
>>
>> > On Thu, Sep 06, 2012 at 12:49:56PM +0300, Michael S. Tsirkin wrote:
>> >> On Thu, Sep 06, 2012 at 02:25:12AM -0700, Kent Overstreet
"Michael S. Tsirkin" writes:
> On Thu, Sep 06, 2012 at 05:27:23PM +0930, Rusty Russell wrote:
>> "Michael S. Tsirkin" writes:
>> > Yes without checksum net core always linearizes packets, so yes it is
>> > screwed.
>> > For -net, skb alwa
Kent Overstreet writes:
> On Thu, Sep 06, 2012 at 12:49:56PM +0300, Michael S. Tsirkin wrote:
>> On Thu, Sep 06, 2012 at 02:25:12AM -0700, Kent Overstreet wrote:
>> > Do you not understand the difference between depends an selects?
>> > Or did you not read my original mail?
Now you're getting in
Paolo Bonzini writes:
> Instead, VIRTIO_NET_F_HOST_MUST_SEND_GARP would be a "negative" feature:
> if set, the host _may not_ rely on the guest to send a gARP. Similarly
> if VIRTIO_BALLOON_F_MUST_TELL_HOST is set, the guest _may not_ use
> ballooned pages directly.
>
> There are _no_ other negat
"Michael S. Tsirkin" writes:
> Yes without checksum net core always linearizes packets, so yes it is
> screwed.
> For -net, skb always allocates space for 17 frags + linear part so
> it seems sane to do same in virtio core, and allocate, for -net,
> up to max_frags + 1 from cache.
> We can adjust
amically when the ring is
under stress.
Note: to stress this, I reduced the ring size to 32 in lguest, and a
1G send reduced the threshold to 9.
Note2: I moved the BUG_ON()s above the indirect test, where they belong
(indirect falls thru on OOM, so the constraints still apply).
Signed-off-by: Rusty Ru
Sasha Levin writes:
>> On Wed, Aug 29, 2012 at 05:03:03PM +0200, Sasha Levin wrote:
>>> I've also re-ran it on a IBM server type host instead of my laptop. Here
>>> are the
>>> results:
>>>
>>> Vanilla kernel:
>>>
>>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
>>> 192.168.
"Michael S. Tsirkin" writes:
> virtio network device multiqueue support reserves
> vq 3 for future use (useful both for future extensions and to make it
> pretty - this way receive vqs have even and transmit - odd numbers).
> Make it possible to skip initialization for
> specific vq numbers by sp
e force the affinity hint
> - if the virtqueues share MSI, make the affinity OR over all affinities
> requested
>
> Signed-off-by: Jason Wang
> Signed-off-by: Paolo Bonzini
Applied, thanks.
Acked-by: Rusty Russell
Cheers,
Rusty.
___
Vir
Paolo Bonzini writes:
> Il 02/07/2012 02:29, Rusty Russell ha scritto:
>> VIRTIO_BALLOON_F_MUST_TELL_HOST
>> implies you should tell the host (eventually). I don't know if any
>> implementations actually care though.
>
> This is indeed broken, because it is a
Dan Carpenter writes:
> Smatch complains about the inconsistent NULL checking here. Fix it to
> return NULL on failure.
>
> Signed-off-by: Dan Carpenter
> ---
> This is only needed in linux-next.
Nice!
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 2edfb5c..457
"Michael S. Tsirkin" writes:
> On Tue, Sep 04, 2012 at 03:53:53PM +0930, Rusty Russell wrote:
>> Kent Overstreet writes:
>>
>> > CONFIG_VIRTIO isn't exposed, everything else is supposed to select it
>> > instead.
>>
>> This is a sligh
"Michael S. Tsirkin" writes:
> On Tue, Sep 04, 2012 at 06:58:47PM +0200, Sjur Brændeland wrote:
>> Hi Michael,
>>
>> > Exactly. Though if we just fail load it will be much less code.
>> >
>> > Generally, using a feature bit for this is a bit of a problem though:
>> > normally driver is expected t
at later if we want (probably
by merging the two structures, I'll have to think harder on that).
Acked-by: Rusty Russell
Cheers,
Rusty.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
"Michael S. Tsirkin" writes:
> Also let's add a wrapper at top of file so ifdefs
> do not litter the code like this. For example:
>
> #ifdef CONFIG_HAS_DMA
> #define VIRTIO_CONSOLE_HAS_DMA (1)
> #else
> #define VIRTIO_CONSOLE_HAS_DMA (0)
> #endif
>
> Now use if instead of ifdef.
The driver certai
Kent Overstreet writes:
> CONFIG_VIRTIO isn't exposed, everything else is supposed to select it
> instead.
This is a slight mis-understanding. It's supposed to be selected by
the particular driver, probably virtio_pci in your case.
Cheers,
Rusty.
___
On Wed, 15 Aug 2012 14:28:51 +0300, "Michael S. Tsirkin"
wrote:
> On Wed, Aug 15, 2012 at 12:16:51PM +0100, Mel Gorman wrote:
> > I was thinking of exactly that page->mapping == balloon_mapping check. As I
> > do not know how many active balloon drivers there might be I cannot guess
> > in advanc
On Thu, 9 Aug 2012 15:46:20 +0530, Amit Shah wrote:
> Hi,
>
> On (Tue) 24 Jul 2012 [11:36:57], Yoshihiro YUNOMAE wrote:
> > Hi All,
> >
> > The following patch set provides a low-overhead system for collecting kernel
> > tracing data of guests by a host in a virtualization environment.
>
> So I
On Wed, 15 Aug 2012 17:40:19 +0300, "Michael S. Tsirkin"
wrote:
> On Wed, Aug 15, 2012 at 09:34:58AM -0300, Rafael Aquini wrote:
> > On Tue, Aug 14, 2012 at 10:31:09PM +0300, Michael S. Tsirkin wrote:
> > > > > now CPU1 executes the next instruction:
> > > > >
> > > > > }
> > > > >
> > > > > wh
On Tue, 14 Aug 2012 11:33:20 +0300, "Michael S. Tsirkin"
wrote:
> On Tue, Aug 14, 2012 at 09:29:49AM +0930, Rusty Russell wrote:
> > On Mon, 13 Aug 2012 11:41:23 +0300, "Michael S. Tsirkin"
> > wrote:
> > > On Fri, Aug 10, 2
On Mon, 13 Aug 2012 11:41:23 +0300, "Michael S. Tsirkin"
wrote:
> On Fri, Aug 10, 2012 at 02:55:15PM -0300, Rafael Aquini wrote:
> > +/*
> > + * Populate balloon_mapping->a_ops->freepage method to help compaction on
> > + * re-inserting an isolated page into the balloon page list.
> > + */
> > +v
On Thu, 09 Aug 2012 21:30:29 +0900, Yoshihiro YUNOMAE
wrote:
> Hi All,
>
> The following patch set provides a low-overhead system for collecting kernel
> tracing data of guests by a host in a virtualization environment.
Thankyou!
I've applied this, and it will head into linux-next in the next
cache between writeback and writethrough
Rusty Russell (1):
virtio-blk: return VIRTIO_BLK_F_FLUSH to header.
drivers/block/virtio_blk.c | 115 ---
drivers/char/hw_random/virtio-rng.c | 37 ++-
include/linux/virtio_blk.h |
On Sun, 29 Jul 2012 14:11:15 +0300, "Michael S. Tsirkin"
wrote:
> On Sat, Jul 28, 2012 at 10:21:05AM +0800, Asias He wrote:
> > This patch introduces bio-based IO path for virtio-blk.
> >
> > Compared to request-based IO path, bio-based IO path uses driver
> > provided ->make_request_fn() method
On Fri, 13 Jul 2012 16:38:51 +0800, Asias He wrote:
> This patch introduces bio-based IO path for virtio-blk.
Acked-by: Rusty Russell
I just hope we can do better than a module option in future.
Thanks,
Rusty.
___
Virtualization mailing l
On Fri, 13 Jul 2012 16:38:51 +0800, Asias He wrote:
> Add 'virtio_blk.use_bio=1' to kernel cmdline or 'modprobe virtio_blk
> use_bio=1' to enable ->make_request_fn() based I/O path.
This patch conflicts with Paolo's Bonzini's 'virtio-blk: allow toggling
host cache between writeback and writethrou
On Tue, 24 Jul 2012 15:01:59 +0200, Sasha Levin wrote:
> virtio on it's own was introduced to help solve the fragmentation
> around virtualized devices, so I don't think that the main purpose of
> doing virtio drivers is due to any performance benefits virtio may
> provide.
There's one argument i
On Mon, 23 Jul 2012 22:32:39 +0200, Sasha Levin wrote:
> As it was discussed recently, there's currently no way for the guest to notify
> the host about panics. Further more, there's no reasonable way to notify the
> host of other critical events such as an OOM kill.
I clearly missed the discussi
On Mon, 16 Jul 2012 16:24:37 +0200, Paolo Bonzini wrote:
> This adds an event for changes to LUN parameters, for example capacity. These
> are reported in virtio-blk via configuration changes, and we want a similar
> functionality in virtio-scsi too.
Both applied.
Thanks!
Rusty.
___
On Fri, 13 Jul 2012 01:59:41 +0300, "Michael S. Tsirkin"
wrote:
> It looks like there's a problem in the way virtio config currently
> works: if driver reads config in probe routine, config
> subsequently can change before core sets DRIVER_OK.
> This will not cause an interrupt and so this event
On Thu, 5 Jul 2012 12:08:22 +0200, Paolo Bonzini wrote:
> The old name is part of the userspace API, add it back for compatibility.
>
> Reported-by: Sasha Levin
> Signed-off-by: Paolo Bonzini
> ---
> include/linux/virtio_blk.h |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
On Wed, 4 Jul 2012 13:55:33 +0300, "Michael S. Tsirkin" wrote:
> On Tue, Jul 03, 2012 at 10:17:46AM +0930, Rusty Russell wrote:
> > On Mon, 2 Jul 2012 13:08:19 -0300, Rafael Aquini wrote:
> > > As 'locking in balloon', may I assume the approach I took for
On Thu, 5 Jul 2012 15:22:25 +0300, "Michael S. Tsirkin" wrote:
> On Thu, Jul 05, 2012 at 12:07:07PM +0200, Paolo Bonzini wrote:
> > The KVM list is followed by more people than the generic
> > virtualization@lists.linux-foundation.org mailing list, and is
> > already "de facto" the place where vir
The following changes since commit 02edf6abe01610a5fb379df442de3c837ad99467:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac
(2012-06-18 13:34:25 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.gi
On Tue, 3 Jul 2012 20:48:50 -0300, Rafael Aquini wrote:
> This patch introduces access sychronization to critical elements of struct
> virtio_balloon, in order to allow the thread concurrency compaction/migration
> bits might ended up imposing to the balloon driver on several situations.
>
> Sig
On Mon, 2 Jul 2012 10:33:08 +0300, "Michael S. Tsirkin" wrote:
> In virtio balloon virtqueue_get_buf might now run concurrently with
> virtqueue_kick. I audited both and this seems safe in practice but
> this is not guaranteed by the API.
> Additionally, a spurious interrupt might in theory make
On Tue, 03 Jul 2012 08:39:39 +0800, Asias He wrote:
> On 07/02/2012 02:41 PM, Rusty Russell wrote:
> > Sure, our guest merging might save us 100x as many exits as no merging.
> > But since we're not doing many requests, does it matter?
>
> We can still have many reque
On Mon, 2 Jul 2012 13:08:19 -0300, Rafael Aquini wrote:
> As 'locking in balloon', may I assume the approach I took for the compaction
> case
> is OK and aligned to address these concerns of yours? If not, do not hesitate
> in
> giving me your thoughts, please. I'm respinning a V3 series to addr
On Mon, 02 Jul 2012 10:45:05 +0800, Asias He wrote:
> On 07/02/2012 07:54 AM, Rusty Russell wrote:
> > Confused. So, without merging we get 6k exits (per second?) How many
> > do we get when we use the request-based IO path?
>
> Sorry for the confusion. The numbers were c
On Tue, 19 Jun 2012 10:51:18 +0800, Asias He wrote:
> On 06/18/2012 07:39 PM, Sasha Levin wrote:
> > On Mon, 2012-06-18 at 14:14 +0300, Dor Laor wrote:
> >> On 06/18/2012 01:05 PM, Rusty Russell wrote:
> >>> On Mon, 18 Jun 2012 16:03:23 +0800, Asias He wrote:
> &
On Sun, 1 Jul 2012 12:20:51 +0300, "Michael S. Tsirkin" wrote:
> On Thu, Nov 03, 2011 at 06:12:53PM +1030, Rusty Russell wrote:
> > A virtio driver does virtqueue_add_buf() multiple times before finally
> > calling virtqueue_kick(); previously we only exposed the
On Tue, 26 Jun 2012 16:21:58 -0700, Frank Swiderski wrote:
> On Tue, Jun 26, 2012 at 2:47 PM, Michael S. Tsirkin wrote:
> > Let's assume it's a feature bit: how would you
> > formulate what the feature does *from host point of view*?
>
> In this implementation, the host doesn't keep track of pag
+
> 7 files changed, 280 insertions(+), 33 deletions(-)
>
>
> V2: address Mel Gorman's review comments
If Mel is happy, I am happy. Seems sensible that the virtio_baloon
changes go in at the same time as the mm changes, so:
Acked-by: Rusty Russell
Cheers,
Rusty.
_
On Wed, 27 Jun 2012 00:41:06 +0300, "Michael S. Tsirkin"
wrote:
> On Tue, Jun 26, 2012 at 01:32:58PM -0700, Frank Swiderski wrote:
> > This implementation of a virtio balloon driver uses the page cache to
> > "store" pages that have been released to the host. The communication
> > (outside of ta
On Mon, 18 Jun 2012 16:03:23 +0800, Asias He wrote:
> On 06/18/2012 03:46 PM, Rusty Russell wrote:
> > On Mon, 18 Jun 2012 14:53:10 +0800, Asias He wrote:
> >> This patch introduces bio-based IO path for virtio-blk.
> >
> > Why make it optional?
>
> request-b
On Mon, 18 Jun 2012 14:53:10 +0800, Asias He wrote:
> This patch introduces bio-based IO path for virtio-blk.
Why make it optional?
Thanks,
Rusty.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.o
the "load memory,%reg ; inc %reg ; store %reg,memory" can
> be interrupted.
>
> So if you are 100% sure all paths are safe against preemption/BH, then
> this patch is not needed, but a big comment in the code would avoid
On Wed, 30 May 2012 15:39:05 +0200, Christian Borntraeger
wrote:
> On 30/05/12 15:19, Stefan Hajnoczi wrote:
> > Holding the vblk->lock across kick causes poor scalability in SMP
> > guests. If one CPU is doing virtqueue kick and another CPU touches the
> > vblk->lock it will have to spin until
On Fri, 1 Jun 2012 10:51:38 +0300, Ohad Ben-Cohen wrote:
> On Fri, Jun 1, 2012 at 10:31 AM, Sjur BRENDELAND
> wrote:
> > if (virtio_has_feature(vdev, VIRTIO_CONSOLE_USE_DMA_MEM)) {
> > dma_addr_t dma;
> > buf = dma_alloc_coherent(dev, size, &dma, GFP_KERNEL);
On Fri, 25 May 2012 10:34:46 +0800, Asias He wrote:
> This patch set fixes the race when hot-unplug stressed disk.
>
> Asias He (3):
> virtio-blk: Call del_gendisk() before disable guest kick
> virtio-blk: Reset device after blk_cleanup_queue()
> virtio-blk: Use block layer provided spinloc
601 - 700 of 1795 matches
Mail list logo