search for: rsp_prod

Hi, We are running into a situation where rsp_prod index in the shared ring is not getting updated for the netfront tx ring by the netback. We see that rsp_cons is the same value as rsp_prod, with req_prod 236 slots away(tx ring is full). From looking at the netfront driver code, it looks as if xennet_tx_buf_gc processing only happens if rsp_p...

Hi, We are running into a situation where rsp_prod index in the shared ring is not getting updated for the netfront tx ring by the netback. We see that rsp_cons is the same value as rsp_prod, with req_prod 236 slots away(tx ring is full). From looking at the netfront driver code, it looks as if xennet_tx_buf_gc processing only happens if rsp_p...

upstream commit 7e96287ddc4f42081e18248b6167041c0908004c Author: Vivek Goyal <vgoyal@in.ibm.com> [PATCH] kdump: introduce "reset_devices" command line option Resetting the devices during driver initialization can be a costly operation in terms of time (especially scsi devices). This option can be used by drivers to know that user forcibly wants the devices to

...\ (_r)->sring->req_prod = (_r)->req_prod_pvt; \ } while (0) #define RING_PUSH_RESPONSES(_r) do { \ - wmb(); /* front sees responses /before/ updated producer index */ \ + virt_wmb(); /* front sees responses /before/ updated producer index */ \ (_r)->sring->rsp_prod = (_r)->rsp_prod_pvt; \ } while (0) @@ -250,9 +250,9 @@ struct __name##_back_ring { \ #define RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(_r, _notify) do { \ RING_IDX __old = (_r)->sring->req_prod; \ RING_IDX __new = (_r)->req_prod_pvt; \ - wmb(); /* back sees re...

...\ (_r)->sring->req_prod = (_r)->req_prod_pvt; \ } while (0) #define RING_PUSH_RESPONSES(_r) do { \ - wmb(); /* front sees responses /before/ updated producer index */ \ + __smp_wmb(); /* front sees responses /before/ updated producer index */ \ (_r)->sring->rsp_prod = (_r)->rsp_prod_pvt; \ } while (0) @@ -250,9 +250,9 @@ struct __name##_back_ring { \ #define RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(_r, _notify) do { \ RING_IDX __old = (_r)->sring->req_prod; \ RING_IDX __new = (_r)->req_prod_pvt; \ - wmb(); /* back sees re...

...01 11:36:51 2009 +0100 +++ b/xen/include/public/io/ring.h Thu Oct 01 02:11:45 2009 +0800 @@ -97,7 +97,8 @@ struct __name##_sring { struct __name##_sring { \ RING_IDX req_prod, req_event; \ RING_IDX rsp_prod, rsp_event; \ - uint8_t pad[48]; \ + uint8_t netfront_smartpoll_active; \ + uint8_t pad[47]; \ union __name##_sr...

...function to operate it ,but it came to oops:     struct xenstore_domain_interface {     char req[XENSTORE_RING_SIZE]; /* Requests to xenstore daemon. */     char rsp[XENSTORE_RING_SIZE]; /* Replies and async watch events. */     XENSTORE_RING_IDX req_cons, req_prod;     XENSTORE_RING_IDX rsp_cons, rsp_prod;     };     struct xenstore_domain_interface *xenstore;     xen_hvm_param_t param;     param.domid = DOMID_SELF;     param.index = HVM_PARAM_STORE_PFN;     if ( hypercall_hvm_op(HVMOP_get_param, &param) )         BUG();     xenstore = (void *) (unsigned long) (param.value << PAGE_SHIFT);...

...dprintf(1,"In notify before hypercall port is %d\n",send.port); //hypercall_event_channel_op(EVTCHNOP_send, &send); dprintf(1,"HYPERCALL read operation notify res %d\n", hypercall_event_channel_op(EVTCHNOP_send,&send)); } ring_res = RING_GET_RESPONSE((priv),(temp->rsp_prod)); Then I get: FAIL RING RESPONSE 0x0009a040 id:256 status:9 operation 0 this is the line: dprintf(1,"FAIL RING RESPONSE %p id:%d status:%d operation %d\n", ring_res,ring_res->id,ring_res->status,ring_res->operation); The id should be the same on both the request and respons...

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

...TRUE) { + UNREFERENCED_PARAMETER(StartContext); + + for (;;) + { KeWaitForSingleObject(&XenBus_ReadThreadEvent, Executive, KernelMode, FALSE, NULL); KdPrint((__DRIVER_NAME " ReadThread Woken (Count = %d)\n", ReadThreadWaitCount++)); while (xen_store_interface->rsp_prod != xen_store_interface->rsp_cons) { @@ -553,7 +561,9 @@ XenBus_WatchThreadProc(PVOID StartContex int index; PXENBUS_WATCH_ENTRY entry; - while(TRUE) + UNREFERENCED_PARAMETER(StartContext); + + for (;;) { KeWaitForSingleObject(&XenBus_WatchThreadEvent, Executive, KernelMode,...

Hi Andi, This series of patches implements the Xen paravirt-ops interface. It applies to 2.6.21-rc7 + your patches + the last batch of pv_ops patches I posted. This patch generally restricts itself to Xen-specific parts of the tree, though it does make a few small changes elsewhere. These patches include: - some helper routines for allocating address space and walking pagetables - Xen

Hi Andi, This series of patches implements the Xen paravirt-ops interface. It applies to 2.6.21-rc7 + your patches + the last batch of pv_ops patches I posted. This patch generally restricts itself to Xen-specific parts of the tree, though it does make a few small changes elsewhere. These patches include: - some helper routines for allocating address space and walking pagetables - Xen

Hi Andi, This series of patches implements the Xen paravirt-ops interface. It applies to 2.6.21-git13 + patches-2.6.21-git7-070507-1.tar.gz (I think "unwinder" is the only patch which doesn't apply to git13, and the sched-clock patches are the only ones which this series actually needs). Changes since the last posting: - More netfront review and cleanup - Added ability to

Hi Andi, This series of patches implements the Xen paravirt-ops interface. It applies to 2.6.21-git13 + patches-2.6.21-git7-070507-1.tar.gz (I think "unwinder" is the only patch which doesn't apply to git13, and the sched-clock patches are the only ones which this series actually needs). Changes since the last posting: - More netfront review and cleanup - Added ability to

Hi Andi, This series of patches implements the Xen paravirt-ops interface. It applies to 2.6.21-git13 + patches-2.6.21-git7-070507-1.tar.gz (I think "unwinder" is the only patch which doesn't apply to git13, and the sched-clock patches are the only ones which this series actually needs). Changes since the last posting: - More netfront review and cleanup - Added ability to

Hi, This is the Xen implementation for the paravirt_ops interface. The series is based on 2.6.22-rc1-mm1, and I think its ready to be cooked in -mm with a view to being merged in 2.6.23. The first part of the series is some small changes to the core kernel. Apart from the new code added in "Allocate and free vmalloc areas" (posted many times before), they are simply a few one-liners

Hi, This is the Xen implementation for the paravirt_ops interface. The series is based on 2.6.22-rc1-mm1, and I think its ready to be cooked in -mm with a view to being merged in 2.6.23. The first part of the series is some small changes to the core kernel. Apart from the new code added in "Allocate and free vmalloc areas" (posted many times before), they are simply a few one-liners