search for: vnet

...@ static int virtio_net_can_receive(void *opaque) return (n->vdev.status & VIRTIO_CONFIG_S_DRIVER_OK) && n->can_receive; } -static void virtio_net_receive(void *opaque, const uint8_t *buf, int size) +void virtio_net_poll(void) { - VirtIONet *n = opaque; + VirtIONet *vnet; + int len; + fd_set rfds; + struct timeval tv; + int max_fd = -1; VirtQueueElement elem; struct virtio_net_hdr *hdr; - int offset, i; - - /* FIXME: the drivers really need to set their status better */ - if (n->rx_vq->vring.avail == NULL) { - n->can_recei...

...@ static int virtio_net_can_receive(void *opaque) return (n->vdev.status & VIRTIO_CONFIG_S_DRIVER_OK) && n->can_receive; } -static void virtio_net_receive(void *opaque, const uint8_t *buf, int size) +void virtio_net_poll(void) { - VirtIONet *n = opaque; + VirtIONet *vnet; + int len; + fd_set rfds; + struct timeval tv; + int max_fd = -1; VirtQueueElement elem; struct virtio_net_hdr *hdr; - int offset, i; - - /* FIXME: the drivers really need to set their status better */ - if (n->rx_vq->vring.avail == NULL) { - n->can_recei...

On 2020/5/6 ??4:21, Jesper Dangaard Brouer wrote: > On Wed, 6 May 2020 14:16:32 +0800 > Jason Wang <jasowang at redhat.com> wrote: > >> We tried to reserve space for vnet header before >> xdp.data_hard_start. But this is useless since the packet could be >> modified by XDP which may invalidate the information stored in the >> header and > IMHO above statements are wrong. XDP cannot access memory before > xdp.data_hard_start. Thus, it is safe...

On 2020/5/6 ??4:21, Jesper Dangaard Brouer wrote: > On Wed, 6 May 2020 14:16:32 +0800 > Jason Wang <jasowang at redhat.com> wrote: > >> We tried to reserve space for vnet header before >> xdp.data_hard_start. But this is useless since the packet could be >> modified by XDP which may invalidate the information stored in the >> header and > IMHO above statements are wrong. XDP cannot access memory before > xdp.data_hard_start. Thus, it is safe...

This patch fixes the tools/vnet makefiles so that vnets will compile and includes updates to the vnet implementation. Vnet ids are increased to 128 bits. The vnet module will insmod whether xen-br0 exists or not. Signed-off-by: Mike Wray <mike.wray@hp.com> _______________________________________________ Xen-devel mailing...

Can i assign static vnet* device for some guests?

On 2020/5/6 ??3:53, Michael S. Tsirkin wrote: > On Wed, May 06, 2020 at 02:16:32PM +0800, Jason Wang wrote: >> We tried to reserve space for vnet header before >> xdp.data_hard_start. But this is useless since the packet could be >> modified by XDP which may invalidate the information stored in the >> header and there's no way for XDP to know the existence of the vnet >> header currently. > What do you mean? Do...

On 2020/5/6 ??3:53, Michael S. Tsirkin wrote: > On Wed, May 06, 2020 at 02:16:32PM +0800, Jason Wang wrote: >> We tried to reserve space for vnet header before >> xdp.data_hard_start. But this is useless since the packet could be >> modified by XDP which may invalidate the information stored in the >> header and there's no way for XDP to know the existence of the vnet >> header currently. > What do you mean? Do...

...On my host node i using system created bridge. example >> >> brctl show br1 >> bridge name bridge id STP enabled interfaces >> br1 8000.0025907925d3 no eth1 >> vnet0 >> vnet2 >> vnet3 >> >> vnetN - guest net adapter, It added to bridge at guest's node started. >> >> bridge defined as >> == >> <...

We copy vnet header unconditionally in page_to_skb() this is wrong since XDP may modify the packet data. So let's keep a zeroed vnet header for not confusing the conversion between vnet header and skb metadata. In the future, we should able to detect whether or not the packet was modified and keep using th...

On Wed, May 06, 2020 at 04:34:36PM +0800, Jason Wang wrote: > > On 2020/5/6 ??4:21, Jesper Dangaard Brouer wrote: > > On Wed, 6 May 2020 14:16:32 +0800 > > Jason Wang <jasowang at redhat.com> wrote: > > > > > We tried to reserve space for vnet header before > > > xdp.data_hard_start. But this is useless since the packet could be > > > modified by XDP which may invalidate the information stored in the > > > header and > > IMHO above statements are wrong. XDP cannot access memory before > > xdp.data_h...

We tried to reserve space for vnet header before xdp.data_hard_start. But this is useless since the packet could be modified by XDP which may invalidate the information stored in the header and there's no way for XDP to know the existence of the vnet header currently. So let's just not reserve space for vnet header in this...

We tried to reserve space for vnet header before xdp.data_hard_start. But this is useless since the packet could be modified by XDP which may invalidate the information stored in the header and there's no way for XDP to know the existence of the vnet header currently. So let's just not reserve space for vnet header in this...

28.10.2016 23:32, Michal Privoznik пишет: On my host node i using system created bridge. example brctl show br1 bridge name bridge id STP enabled interfaces br1 8000.0025907925d3 no eth1 vnet0 vnet2 vnet3 vnetN - guest net adapter, It added to bridge at guest's node started. bridge defined as == <network> <name>internal</name> <forward mode="bri...

...> >> In general it sounds like std::call_once may not really be bug free. >> >> Jiangning, can you please provide your gcc/libstdc++ version? >> >> Thanks, >> -Chris >> >> >> > On Nov 4, 2014, at 9:38 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> >> wrote: >> > >> > On Tue, 2014-11-04 at 12:17 -0500, Samuel F Antao wrote: >> >> Ok, I'll put a patch together to fix this later today. I'll probably >> >> do what Reid was suggesting and use what is already in there for >>...

Ok, I'll put a patch together to fix this later today. I'll probably do what Reid was suggesting and use what is already in there for Windows. Thanks, Samuel Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote on 11/04/2014 12:11:08 PM: > From: Bill Schmidt <wschmidt at linux.vnet.ibm.com> > To: Samuel F Antao/Watson/IBM at IBMUS > Cc: azanella at linux.vnet.ibm.com, beanz at apple.com, Hal Finkel > <hfinkel at anl.gov>, LLVM Dev <llvmdev at cs.uiuc.edu> &...

...Jiangning reported a similar issue on the llvm-commits list on Debian aarch64. In general it sounds like std::call_once may not really be bug free. Jiangning, can you please provide your gcc/libstdc++ version? Thanks, -Chris > On Nov 4, 2014, at 9:38 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > On Tue, 2014-11-04 at 12:17 -0500, Samuel F Antao wrote: >> Ok, I'll put a patch together to fix this later today. I'll probably >> do what Reid was suggesting and use what is already in there for >> Windows. > > Hm, better hold off on...

...*is* in the status xml (i.e. the output of "visrh dumpxml >> $domain" while the domain is running, and also the xml provided on stdin >> to the qemu and network hooks when they are called). >> >> (also, what Vincent said in his email - names with the prefix "vnet" are >> assumed to be "leftover" from a previous instance of the domain (for >> better or worse) an replaced with an autogenerated name. But if you >> supply a name that doesn't start with "vnet", it will be used). > > > Hmm. What right way to...

Deep in the discussion of this bug, unfortunately mostly in private comments: https://bugzilla.redhat.com/show_bug.cgi?id=1594515 we decided it'd be more flexible for RHV if we had a way to map individual NICs to target networks and bridges. This can be done by adding a new --mac option so you can specify the exact mapping you need: $ virt-v2v [...] \ --mac

...dislav Yasevich wrote: >> Curreclty virtion net header is fixed size and adding things to it is rather >> difficult to do. This series attempt to add the infrastructure as well as some >> extensions that try to resolve some deficiencies we currently have. >> >> First, vnet header only has space for 16 flags. This may not be enough >> in the future. The extensions will provide space for 32 possbile extension >> flags and 32 possible extensions. These flags will be carried in the >> first pseudo extension header, the presense of which will be dete...