lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090929132405.GB23395@amit-x200.redhat.com>
Date:	Tue, 29 Sep 2009 18:54:05 +0530
From:	Amit Shah <amit.shah@...hat.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	alan@...ux.intel.com, virtualization@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] virtio_console: Add support for multiple ports for
	generic guest and host communication

On (Tue) Sep 29 2009 [22:41:45], Rusty Russell wrote:
> On Fri, 11 Sep 2009 11:43:06 pm Amit Shah wrote:
> > Expose multiple char devices ("ports") for simple communication
> > between the host userspace and guest.
> 
> OK, I think other comments have died down, so it's time for a review.  This
> was the latest patch I could find.

I just sent a new patch in this thread; can you please review that one?

> The obvious way to do this is to use multiple pairs of virtqueues.  Is this
> silly for some reason?  Yes, we're restricted to 32k ports.

There were a couple of things to note about that:
- Avi, in the past, mentioned separate ivq and ovqs for each port for
  the kind of usage intended would be overkill.
- With the MSI rework, we can't init new i/ovqs for hotplugged ports as
  we find them. The queues all have to be init'ed at probe() time. I had
  some discussion with Michael some time back on virtualization@, but
  thought the overhead of implementing that would be high.

> It means that if we see the MULTIQUEUE feature, we can look for the other
> queues.  Our current MSI-X friendly API makes that a little painful, but
> if we resolve that our code should be sweetness, no?

If this is to solve the port numbering, etc., issues, I've thought of a
new way this can be done in the newest patch. What's more, Christian
tested it on s390 as well and it worked with a minor tweak. I tested the
new patch with combinations of qemu and kernel (old/new) and they worked
fine.

Thanks,
		Amit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ