Re: [Qemu-devel] [dpdk-dev] dpdk/vpp and cross-version migration for vhost
>
>On 11/24/2016 12:47 PM, Maxime Coquelin wrote:
>>
>>
>> On 11/24/2016 01:33 PM, Yuanhan Liu wrote:
>>> On Thu, Nov 24, 2016 at 09:30:49AM +, Kevin Traynor wrote:
> On 11/24/2016 06:31 AM, Yuanhan Liu wrote:
> > > On Tue, Nov 22, 2016 at 04:53:05PM +0200, Michael S. Tsirkin wrote:
> You keep assuming that you have the VM started first and
> figure out things afterwards, but this does not work.
>
> Think about a cluster of machines. You want to start a VM in
> a way that will ensure compatibility with all hosts
> in a cluster.
>>> > >>>
>>> > >>> I see. I was more considering about the case when the dst
>>> > >>> host (including the qemu and dpdk combo) is given, and
>>> > >>> then determine whether it will be a successfull migration
>>> > >>> or not.
>>> > >>>
>>> > >>> And you are asking that we need to know which host could
>>> > >>> be a good candidate before starting the migration. In such
>>> > >>> case, we indeed need some inputs from both the qemu and
>>> > >>> vhost-user backend.
>>> > >>>
>>> > >>> For DPDK, I think it could be simple, just as you said, it
>>> > >>> could be either a tiny script, or even a macro defined in
>>> > >>> the source code file (we extend it every time we add a
>>> > >>> new feature) to let the libvirt to read it. Or something
>>> > >>> else.
>> > >>
>> > >> There's the issue of APIs that tweak features as Maxime
>> > >> suggested.
> > >
> > > Yes, it's a good point.
> > >
>> > >> Maybe the only thing to do is to deprecate it,
> > >
> > > Looks like so.
> > >
>> > >> but I feel some way for application to pass info into
>> > >> guest might be benefitial.
> > >
> > > The two APIs are just for tweaking feature bits DPDK supports
> before
> > > any device got connected. It's another way to disable some features
> > > (the another obvious way is to through QEMU command lines).
> > >
> > > IMO, it's bit handy only in a case like: we have bunch of VMs.
> Instead
> > > of disabling something though qemu one by one, we could disable it
> > > once in DPDK.
> > >
> > > But I doubt the useful of it. It's only used in DPDK's vhost
> example
> > > after all. Nor is it used in vhost pmd, neither is it used in OVS.
>
> rte_vhost_feature_disable() is currently used in OVS,
lib/netdev-dpdk.c
>>> Hmmm. I must have checked very old code ...
>
> netdev_dpdk_vhost_class_init(void)
> {
> static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
>
> /* This function can be called for different classes. The
> initialization
> * needs to be done only once */
> if (ovsthread_once_start()) {
> rte_vhost_driver_callback_register(_net_device_ops);
> rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_HOST_TSO4
> | 1ULL << VIRTIO_NET_F_HOST_TSO6
> | 1ULL << VIRTIO_NET_F_CSUM);
>>> I saw the commit introduced such change, but it tells no reason why
>>> it was added.
>>
>> I'm also interested to know the reason.
>
>I can't remember off hand, added Mark K or Michal W who should be able
>to shed some light on it.
DPDK v16.04 added support for vHost User TSO; as such, by default, TSO is
advertised to guest devices as an available feature during feature negotiation
with QEMU.
However, while the vHost user backend sets up the majority of the mbuf fields
that are required for TSO, there is still a reliance on the associated DPDK
application (i.e. in this case OvS-DPDK) to set the remaining flags and/or
offsets. Since OvS-DPDK doesn't currently provide that functionality, it is
necessary to explicitly disable TSO; otherwise, undefined behaviour will ensue.
>
>> In any case, I think this is something that can/should be managed by
>> the management tool, which should disable it in cmd parameters.
>>
>> Kevin, do you agree?
>
>I think best to find out the reason first. Because if no reason to
>disable in the code, then no need to debate!
>
>>
>> Cheers,
>> Maxime
RE: [Qemu-devel] USB EHCI development nearing completion
Paul, I don't see anything to do with EHCI in Chromium. I was just referring to the 3D patch as an example - maybe this is causing confusion. Did anyone else get a chance to look at the EHCI emulation patch? Thanks, Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Brook Sent: 27 December 2006 21:34 To: qemu-devel@nongnu.org Cc: Mark B Subject: Re: [Qemu-devel] USB EHCI development nearing completion On Wednesday 27 December 2006 21:21, Mark B wrote: Thank you Fabrice and co. LGPL or BSD should be fine - I don't have any preference on the license. I could not find the experimental 3D patch - it seems to have expired. But I uploaded a diff patch anyway to 4shared at this location: http://www.4shared.com/file/7986451/d1222873/ehci.html This is an early proof of concept with a good bit of tidying up yet to be done. It is not yet for public release either. But of course comments and other feedback are welcome. Have you looked at Chromium (http://chromium.sourceforge.net/) It looks like what they've already achieved what you're trying to implement. It just needs a qemu specific transport implementation. It already has multiple transport backends to support TCP/IP and FiberChannel. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] USB EHCI development nearing completion
Thank you Fabrice and co. LGPL or BSD should be fine - I don't have any preference on the license. I could not find the experimental 3D patch - it seems to have expired. But I uploaded a diff patch anyway to 4shared at this location: http://www.4shared.com/file/7986451/d1222873/ehci.html This is an early proof of concept with a good bit of tidying up yet to be done. It is not yet for public release either. But of course comments and other feedback are welcome. Mark -Original Message- From: Fabrice Bellard [mailto:[EMAIL PROTECTED] Sent: 27 December 2006 13:39 To: qemu-devel@nongnu.org Cc: [EMAIL PROTECTED] Subject: Re: [Qemu-devel] USB EHCI development nearing completion Another point is that I won't accept a GPL license for such a device. LGPL or BSD would be better. Regards, Fabrice. Hetz Ben Hamo wrote: Hi Mark, Well, there aren't any written rules but most people who contribute sends some proof of concept diff'ed patch (appliable to QEMU CVS for example) (you can look at the experimental 3D patch few weeks ago), and then the talks begins, while others would look how portable your code to other platforms/OS's.. Thanks, Hetz On 12/24/06, Mark B [EMAIL PROTECTED] wrote: Dear list, Just a quick note to let you know I have almost finished an implementation of an EHCI host controller for USB (usb-ehci.c) for qemu. I am testing with an XP guest and so far I have a mass storage flash key, a mouse and a tablet working. I haven't yet implemented isochronous or split transactions though. It doesn't do companion controller hand-offs for low or full speed devices either but Windows XP doesn't mind that I am attaching low/full speed devices through EHCI (I believe Linux guests won't like this). I have asked the company I am working for to give me permission to GPL the module and so far they are agreeable. So I am planning to clean up and have an initial version for check in early in the new year. If anyone has any inputs, please do let me know. I'm new to qemu development so am not sure of checkin etiquette, etc. Pointers in that regard appreciated too. Cheers, Mark ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] USB EHCI development nearing completion
Dear list, Just a quick note to let you know I have almost finished an implementation of an EHCI host controller for USB (usb-ehci.c) for qemu. I am testing with an XP guest and so far I have a mass storage flash key, a mouse and a tablet working. I havent yet implemented isochronous or split transactions though. It doesnt do companion controller hand-offs for low or full speed devices either but Windows XP doesnt mind that I am attaching low/full speed devices through EHCI (I believe Linux guests wont like this). I have asked the company I am working for to give me permission to GPL the module and so far they are agreeable. So I am planning to clean up and have an initial version for check in early in the new year. If anyone has any inputs, please do let me know. Im new to qemu development so am not sure of checkin etiquette, etc. Pointers in that regard appreciated too. Cheers, Mark ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
