search for: notify_remote_via_evtchn

...len -= avail; /* Other side must not see new producer until data is * there. */ wmb(); intf->req_prod += avail; /* Implies mb(): other side will see the updated producer. */ notify_remote_via_evtchn(xen_store_evtchn); To me, it looks like for guests compiled with CONFIG_SMP, smp_wmb and smp_mb would be sufficient, so mb() and wmb() here are only needed if a non-SMP guest runs on an SMP host. Is my analysis correct? So what I'm suggesting is something like the below patch, except instead...

...len -= avail; /* Other side must not see new producer until data is * there. */ wmb(); intf->req_prod += avail; /* Implies mb(): other side will see the updated producer. */ notify_remote_via_evtchn(xen_store_evtchn); To me, it looks like for guests compiled with CONFIG_SMP, smp_wmb and smp_mb would be sufficient, so mb() and wmb() here are only needed if a non-SMP guest runs on an SMP host. Is my analysis correct? So what I'm suggesting is something like the below patch, except instead...

...dependency, but let''s play safe). */ + mb(); + memcpy(dst, data, avail); data += avail; len -= avail; + + /* Other side must not see new header until data is there. */ + wmb(); update_output_chunk(out, avail); + + /* This implies mb() before other side sees interrupt. */ notify_remote_via_evtchn(xen_start_info->store_evtchn); } while (len != 0); @@ -171,7 +181,6 @@ wait_event_interruptible(xb_waitq, xs_input_avail()); - mb(); h = *in; if (!check_buffer(&h)) return -EIO; @@ -183,13 +192,21 @@ avail = len; was_full = !output_avail(&h); + /* We must...

Hi experts I use xen-4.0.0 and dom0 is 2.6.33 and domU is 2.6.34 #lspci ............... 01:00.0 Ethernet controller: Intel Corporation Unknown device 10a7 (rev 02) 01:00.1 Ethernet controller: Intel Corporation Unknown device 10a7 (rev 02) 05:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 05:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit

...> /* Other side must not see new producer until data is * there. */ > wmb(); > intf->req_prod += avail; > > /* Implies mb(): other side will see the updated producer. */ > notify_remote_via_evtchn(xen_store_evtchn); > > To me, it looks like for guests compiled with CONFIG_SMP, smp_wmb and smp_mb > would be sufficient, so mb() and wmb() here are only needed if > a non-SMP guest runs on an SMP host. > > Is my analysis correct? For x86, yes. For arm/arm64 I think so, but w...

.../events.h +++ b/include/xen/events.h @@ -31,6 +31,7 @@ int bind_ipi_to_irqhandler(enum ipi_vector ipi, void unbind_from_irqhandler(unsigned int irq, void *dev_id); void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector); +int resend_irq_on_evtchn(unsigned int irq); static inline void notify_remote_via_evtchn(int port) { -- 1.5.3 -- yamahata

...x_sem); local_irq_save(flags); + id = get_id_from_freelist(tx_freelist); + local_irq_restore(flags); - id = get_id_from_freelist(tx_freelist); buf = &tx_buffers[id]; page = buf->page; @@ -461,7 +463,7 @@ void netfront_xmit(unsigned char* data,i if(notify) notify_remote_via_evtchn(info->evtchn); + local_irq_save(flags); network_tx_buf_gc(); - local_irq_restore(flags); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

.../events.h +++ b/include/xen/events.h @@ -31,6 +31,7 @@ int bind_ipi_to_irqhandler(enum ipi_vector ipi, void unbind_from_irqhandler(unsigned int irq, void *dev_id); void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector); +int resend_irq_on_evtchn(unsigned int irq); static inline void notify_remote_via_evtchn(int port) { -- 1.5.3 -- yamahata

...> /* Other side must not see new producer until data is * there. */ > wmb(); > intf->req_prod += avail; > > /* Implies mb(): other side will see the updated producer. */ > notify_remote_via_evtchn(xen_store_evtchn); > > To me, it looks like for guests compiled with CONFIG_SMP, smp_wmb and smp_mb > would be sufficient, so mb() and wmb() here are only needed if > a non-SMP guest runs on an SMP host. > > Is my analysis correct? Correct. The reason full barriers are used is s...

On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 03:16:20PM +0200, Michael S. Tsirkin wrote: > > On Thu, Dec 17, 2015 at 11:52:38AM +0100, Peter Zijlstra wrote: > > > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > > > +static inline void virtio_store_mb(bool weak_barriers, > > > > +

On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 03:16:20PM +0200, Michael S. Tsirkin wrote: > > On Thu, Dec 17, 2015 at 11:52:38AM +0100, Peter Zijlstra wrote: > > > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > > > +static inline void virtio_store_mb(bool weak_barriers, > > > > +

Hi. Recently the xen-ia64 community started to make efforts to merge xen/ia64 Linux to upstream. The first step is to merge up domU portion. This patchset is preliminary for xen/ia64 domU linux making the current xen/x86 domU code more arch generic and adding missing definitions and files. Diffstat: arch/x86/xen/Makefile | 4 +- arch/x86/xen/grant-table.c | 91

Hi. Recently the xen-ia64 community started to make efforts to merge xen/ia64 Linux to upstream. The first step is to merge up domU portion. This patchset is preliminary for xen/ia64 domU linux making the current xen/x86 domU code more arch generic and adding missing definitions and files. Diffstat: arch/x86/xen/Makefile | 4 +- arch/x86/xen/grant-table.c | 91

Hi. Recently the xen-ia64 community started to make efforts to merge xen/ia64 Linux to upstream. The first step is to merge up domU portion. This patchset is preliminary for xen/ia64 domU linux making the current xen/x86 domU code more arch generic and adding missing definitions and files. Diffstat: arch/x86/xen/Makefile | 4 +- arch/x86/xen/grant-table.c | 91

Hello, Sometimes the backend of PVFB knows that it doesn''t need permanent refresh, when the window is minimized for instance (no refresh at all), or the administration tools know that the window is thumnailed, and so a slow refresh rate is fine. Also, some users may want to tune the refresh rate according to the smoothness they would like, balanced with the CPU time that requires.

...ze %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->resp_len); @@ -1003,6 +982,7 @@ void send_response(tpmcmd_t* cmd, tpmif_t* tpmif) #endif /* clear the ready flag and send the event channel notice to the frontend */ tpmif_req_finished(tpmif); + shr->state = 0; notify_remote_via_evtchn(tpmif->evtchn); error: local_irq_restore(flags); diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c index 0218d7f..bcee93d 100644 --- a/extras/mini-os/tpmfront.c +++ b/extras/mini-os/tpmfront.c @@ -153,6 +153,32 @@ static int wait_for_backend_closed(xenbus_event_queue* event...

Hi Jeremy. According to your suggestion, I recreated patches for Ingo's x86.git tree. And this patch series includes Eddie's modification. Please review and forward them. (or push back to respin.) Recently the xen-ia64 community started to make efforts to merge xen/ia64 Linux to upstream. The first step is to merge up domU portion. This patchset is preliminary for xen/ia64 domU linux

Hi Jeremy. According to your suggestion, I recreated patches for Ingo's x86.git tree. And this patch series includes Eddie's modification. Please review and forward them. (or push back to respin.) Recently the xen-ia64 community started to make efforts to merge xen/ia64 Linux to upstream. The first step is to merge up domU portion. This patchset is preliminary for xen/ia64 domU linux

This patch series implements the Linux Xen guest in terms of the paravirt-ops interface. The features in implemented this patch series are: * domU only * UP only (most code is SMP-safe, but there's no way to create a new vcpu) * writable pagetables, with late pinning/early unpinning (no shadow pagetable support) * supports both PAE and non-PAE modes * xen console * virtual block

This patch series implements the Linux Xen guest in terms of the paravirt-ops interface. The features in implemented this patch series are: * domU only * UP only (most code is SMP-safe, but there's no way to create a new vcpu) * writable pagetables, with late pinning/early unpinning (no shadow pagetable support) * supports both PAE and non-PAE modes * xen console * virtual block