On Wed, Feb 04, 2015 at 11:32:29AM +, Daniel P. Berrange wrote:
> In QEMU there are a number of features which involve communication with an
> external system over an I/O channel of some form. The features include
> migration, NBD, VNC and character devices. The I/O channel in question might
>
On 5 February 2015 at 14:38, Stefan Hajnoczi wrote:
> Yes, the glib 2.12 requirement is too conservative. We can definitely
> move to a higher version.
>
> Red Hat Enterprise Linux 6.6 is on 2.28.
> Debian wheezy (stable) is on glib 2.33.
I'd rather not drop support for Debian oldstable or Ubunt
On Thu, 5 Feb 2015 14:38:36 +
Stefan Hajnoczi wrote:
> On Wed, Feb 04, 2015 at 02:42:20PM +0100, Paolo Bonzini wrote:
> > GIO has TLS bindings (not SASL I think?) in GIO 2.28. Currently we
> > require glib 2.12 (released 2006) on POSIX systems and glib 2.20
> > (released 2009) on Windows. T
On Wed, Feb 04, 2015 at 02:42:20PM +0100, Paolo Bonzini wrote:
> GIO has TLS bindings (not SASL I think?) in GIO 2.28. Currently we
> require glib 2.12 (released 2006) on POSIX systems and glib 2.20
> (released 2009) on Windows. That's very conservative indeed, I wouldn't
> mind changing to a new
* Eric Blake (ebl...@redhat.com) wrote:
> On 02/04/2015 07:02 AM, Daniel P. Berrange wrote:
>
> >>
> >> I think fixing this for migration might simplify stuff for users a lot as
> >> well;
> >> the choice of whether libvirt does tunneling or not and what it means
> >> for how block migration happ
Peter Maydell writes:
> On 4 February 2015 at 16:33, Markus Armbruster wrote:
>> Peter Maydell writes:
>>> On 4 February 2015 at 13:49, Markus Armbruster wrote:
Remind me: what GLib version are we targeting, and why?
>>>
>>> Our current minimum is 2.12 (or 2.20 in Windows specific code),
On 04/02/2015 21:41, Peter Maydell wrote:
> That suggests to me that we could reasonably advance to
> 2.22 or 2.24 if it seemed beneficial, but not beyond that.
> Is there anything particularly worthwhile that would get us?
2.22 is the first version to have GIO.
2.28 would give us TLS support i
On 4 February 2015 at 16:33, Markus Armbruster wrote:
> Peter Maydell writes:
>> On 4 February 2015 at 13:49, Markus Armbruster wrote:
>>> Remind me: what GLib version are we targeting, and why?
>>
>> Our current minimum is 2.12 (or 2.20 in Windows specific code),
>> and the reason is RHEL5/Cent
On 02/04/2015 07:02 AM, Daniel P. Berrange wrote:
>>
>> I think fixing this for migration might simplify stuff for users a lot as
>> well;
>> the choice of whether libvirt does tunneling or not and what it means
>> for how block migration happens etc can get very confusing.
>
> Yes, and not help
On Wed, Feb 04, 2015 at 05:33:36PM +0100, Markus Armbruster wrote:
> Peter Maydell writes:
>
> > On 4 February 2015 at 13:49, Markus Armbruster wrote:
> >> Remind me: what GLib version are we targeting, and why?
> >
> > Our current minimum is 2.12 (or 2.20 in Windows specific code),
> > and the
On 04/02/2015 16:26, Daniel P. Berrange wrote:
> > GIOChannel's advantage is that---even though it may not be used for
> > regular migration---integration with chardev would be really easy.
>
> If we did a QEMUIOChannel that was basically the same as IOChannel, but
> with support for iovec write
Peter Maydell writes:
> On 4 February 2015 at 13:49, Markus Armbruster wrote:
>> Remind me: what GLib version are we targeting, and why?
>
> Our current minimum is 2.12 (or 2.20 in Windows specific code),
> and the reason is RHEL5/Centos 5.
Any idea when we can move on?
Don't get me started on
On 04/02/2015 16:11, Daniel P. Berrange wrote:
> > For GIO/GIOChannel, you'd have to choose between zerocopy and many
> > syscalls, or one copy and few syscalls. Since every page has two iov
> > entries, one of which is just 8 bytes, one copy and few syscalls is
> > probably faster---but still o
On Wed, Feb 04, 2015 at 04:22:26PM +0100, Paolo Bonzini wrote:
>
>
> On 04/02/2015 16:11, Daniel P. Berrange wrote:
> > > For GIO/GIOChannel, you'd have to choose between zerocopy and many
> > > syscalls, or one copy and few syscalls. Since every page has two iov
> > > entries, one of which is j
On Wed, Feb 04, 2015 at 04:04:33PM +0100, Paolo Bonzini wrote:
>
>
> On 04/02/2015 15:34, Daniel P. Berrange wrote:
> > > GIO doesn't provide writev either, so it's not a good match for
> > > non-encrypted migration, which really tries hard to do no copies in
> > > userspace.
> >
> > Ok, maybe R
On 04/02/2015 15:34, Daniel P. Berrange wrote:
> > GIO doesn't provide writev either, so it's not a good match for
> > non-encrypted migration, which really tries hard to do no copies in
> > userspace.
>
> Ok, maybe RDMA will still need QEMUFile, but for non-encrypted TCP
> I'd hope to be able t
On 02/04/2015 04:28 PM, Paolo Bonzini wrote:
On 04/02/2015 15:02, Daniel P. Berrange wrote:
I'm not sure if it makes sense for RDMA; it already has a couple of hooks
that go around the back of QEMUFile in migration, and it's transferring the
data via DMA so the page data doesn't go through the
On Wed, Feb 04, 2015 at 04:48:44PM +0200, Marcel Apfelbaum wrote:
> On 02/04/2015 04:28 PM, Paolo Bonzini wrote:
> >
> >
> >On 04/02/2015 15:02, Daniel P. Berrange wrote:
> >>>I'm not sure if it makes sense for RDMA; it already has a couple of hooks
> >>>that go around the back of QEMUFile in migra
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 04/02/2015 14:08, Dr. David Alan Gilbert wrote:
> > 3) I'd considered making a separate socket/fd for passing page data
> > in the hope of maybe making that page take data via splice; but am not
> > sure yet.
>
> There were even p
On 04/02/2015 14:08, Dr. David Alan Gilbert wrote:
> 3) I'd considered making a separate socket/fd for passing page data
> in the hope of maybe making that page take data via splice; but am not
> sure yet.
There were even patches for this:
http://lists.gnu.org/archive/html/qemu-devel
On Wed, Feb 04, 2015 at 03:23:22PM +0100, Paolo Bonzini wrote:
>
>
> On 04/02/2015 15:08, Daniel P. Berrange wrote:
> >> > As long as QEMUFile remains there and GIOChannel is used only when
> >> > encryption is required, that would be an acceptable limitation. As I
> >> > wrote above, migration
On 04/02/2015 15:02, Daniel P. Berrange wrote:
> > I'm not sure if it makes sense for RDMA; it already has a couple of hooks
> > that go around the back of QEMUFile in migration, and it's transferring the
> > data via DMA so the page data doesn't go through the same path.
>
> Could you ever anti
On 04/02/2015 15:08, Daniel P. Berrange wrote:
>> > As long as QEMUFile remains there and GIOChannel is used only when
>> > encryption is required, that would be an acceptable limitation. As I
>> > wrote above, migration is a bit special anyway.
> I'm not sure I'd like the idea of having differe
On Wed, Feb 04, 2015 at 02:42:20PM +0100, Paolo Bonzini wrote:
>
>
> On 04/02/2015 14:00, Daniel P. Berrange wrote:
> > On Wed, Feb 04, 2015 at 01:43:12PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 04/02/2015 12:32, Daniel P. Berrange wrote:
> >>> So my idea would be that we define a QEMUChann
On Wed, Feb 04, 2015 at 01:08:21PM +, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > In QEMU there are a number of features which involve communication with an
> > external system over an I/O channel of some form. The features include
> > migration, NBD, V
On 4 February 2015 at 13:49, Markus Armbruster wrote:
> Remind me: what GLib version are we targeting, and why?
Our current minimum is 2.12 (or 2.20 in Windows specific code),
and the reason is RHEL5/Centos 5.
-- PMM
"Daniel P. Berrange" writes:
> On Wed, Feb 04, 2015 at 01:43:12PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 04/02/2015 12:32, Daniel P. Berrange wrote:
>> > So my idea would be that we define a QEMUChannel object and set of APIs to
>> > standardize all interaction with sockets, pipes, RDMA, whate
* Daniel P. Berrange (berra...@redhat.com) wrote:
> In QEMU there are a number of features which involve communication with an
> external system over an I/O channel of some form. The features include
> migration, NBD, VNC and character devices. The I/O channel in question might
> might be a FIFO pi
On 04/02/2015 14:00, Daniel P. Berrange wrote:
> On Wed, Feb 04, 2015 at 01:43:12PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 04/02/2015 12:32, Daniel P. Berrange wrote:
>>> So my idea would be that we define a QEMUChannel object and set of APIs to
>>> standardize all interaction with sockets, pipe
On Wed, Feb 04, 2015 at 01:43:12PM +0100, Paolo Bonzini wrote:
>
>
> On 04/02/2015 12:32, Daniel P. Berrange wrote:
> > So my idea would be that we define a QEMUChannel object and set of APIs to
> > standardize all interaction with sockets, pipes, RDMA, whatever $channel,
> > and then convert the
On 04/02/2015 12:32, Daniel P. Berrange wrote:
> So my idea would be that we define a QEMUChannel object and set of APIs to
> standardize all interaction with sockets, pipes, RDMA, whatever $channel,
> and then convert the QEMU features I've mentioned over to use that. I think
> that would be sim
In QEMU there are a number of features which involve communication with an
external system over an I/O channel of some form. The features include
migration, NBD, VNC and character devices. The I/O channel in question might
might be a FIFO pipe, a PTY, a TCP socket, a UNIX domain socket, RMDA channe
32 matches
Mail list logo
