Skip to contentSkip to conversation

Add macros for acessing lguest fields

PATCH In review Glauber de Oliveira Costa 2 participants 3 messages Sep 10, 2007 – Sep 13, 2007 virtio core

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Add macros for acessing lguest fields

The assumption that we have an overall irqs_pending flags, and a one-to-one lguest <-> task mapping fails to hold on x86_64, where we can have multiple puppies, aka vcpus.

Although ifdefs could be used, it makes the code much more unreadable, and other ports are on the way, anyway. So some sort of acessor is preferred anyway.

---
 drivers/lguest/io.c |   10 +++++-----
 drivers/lguest/lg.h |    3 +++
 2 files changed, 8 insertions(+), 5 deletions(-)
drivers/lguest/io.c +5 -5
index ea68613..70bab38 100644
@@ -247,7 +247,7 @@ static int lgread_other(struct lguest *lg,
 			void *buf, u32 addr, unsigned bytes)
 {
 	if (!lguest_address_ok(lg, addr, bytes)
-	    || access_process_vm(lg->tsk, addr, buf, bytes, 0) != bytes) {
+	    || access_process_vm(lguest_task(lg), addr, buf, bytes, 0) != bytes) {
 		memset(buf, 0, bytes);
 		kill_guest(lg, "bad address in registered DMA struct");
 		return 0;
@@ -261,7 +261,7 @@ static int lgwrite_other(struct lguest *lg, u32 addr,
 			 const void *buf, unsigned bytes)
 {
 	if (!lguest_address_ok(lg, addr, bytes)
-	    || (access_process_vm(lg->tsk, addr, (void *)buf, bytes, 1)
+	    || (access_process_vm(lguest_task(lg), addr, (void *)buf, bytes, 1)
 		!= bytes)) {
 		kill_guest(lg, "bad address writing to registered DMA");
 		return 0;
@@ -376,7 +376,7 @@ static u32 do_dma(struct lguest *srclg, const struct lguest_dma *src,
 		 * we only want a single page.  But it works, and returns the
 		 * number of pages.  Note that we're holding the destination's
 		 * mmap_sem, as get_user_pages() requires. */
-		if (get_user_pages(dstlg->tsk, dstlg->mm,
+		if (get_user_pages(lguest_task(dstlg), dstlg->mm,
 				   dst->addr[i], 1, 1, 1, pages+i, NULL)
 		    != 1) {
 			/* This means the destination gave us a bogus buffer */
@@ -469,9 +469,9 @@ static int dma_transfer(struct lguest *srclg,
 	/* We trigger the destination interrupt, even if the destination was
 	 * empty and we didn't transfer anything: this gives them a chance to
 	 * wake up and refill. */
-	set_bit(dst->interrupt, dstlg->irqs_pending);
+	set_bit(dst->interrupt, lguest_irqs_pending(dstlg));
 	/* Wake up the destination process. */
-	wake_up_process(dstlg->tsk);
+	wake_up_process(lguest_task(dstlg));
 	/* If we passed the last "struct lguest_dma", the receive had no
 	 * buffers left. */
 	return i == dst->num_dmas;
drivers/lguest/lg.h +3 -0
index 64f0abe..b1ed671 100644
@@ -258,6 +258,9 @@ unsigned long get_dma_buffer(struct lguest *lg, unsigned long key,
 void do_hypercalls(struct lguest *lg);
 void write_timestamp(struct lguest *lg);
 
+#define lguest_task(__lg) __lg->tsk
+#define lguest_irqs_pending(__lg) __lg->irqs_pending
+
 /*L:035
  * Let's step aside for the moment, to study one important routine that's used
  * widely in the Host code.
Signature · 1 line
1.4.4.2
#1 lore raw
Quoted 7 lines · Glauber de Oliveira Costa

The assumption that we have an overall irqs_pending flags, and a one-to-one lguest <-> task mapping fails to hold on x86_64, where we can have multiple puppies, aka vcpus.

Although ifdefs could be used, it makes the code much more unreadable, and other ports are on the way, anyway. So some sort of acessor is preferred anyway.

I'd prefer to see the i386 code use vcpus too. Even if i386 only has one at present, it's cleaner.

Of course, there'll be a lot of "s/lg/vcpu/" churn, but that's OK.

Thanks,
Rusty.

#2 lore raw
In reply to Glauber de Oliveira Costa
Quoted 7 lines · Glauber de Oliveira Costa

The assumption that we have an overall irqs_pending flags, and a one-to-one lguest <-> task mapping fails to hold on x86_64, where we can have multiple puppies, aka vcpus.

Although ifdefs could be used, it makes the code much more unreadable, and other ports are on the way, anyway. So some sort of acessor is preferred anyway.

I'd prefer to see the i386 code use vcpus too. Even if i386 only has one at present, it's cleaner.

Of course, there'll be a lot of "s/lg/vcpu/" churn, but that's OK.

Thanks,
Rusty.