* Rusty Russell [EMAIL PROTECTED] wrote:
- /* Get the current pte state, but zero it out to make it
- non-present, preventing the hardware from asynchronously
- updating it. */
+ /*
+* Get the current pte state, but zero it out to make it
+* non-present,
On Thu, 2008-05-29 at 16:34 +1000, Rusty Russell wrote:
On Tuesday 27 May 2008 21:06:26 Mark McLoughlin wrote:
On Mon, 2008-05-26 at 17:42 +1000, Rusty Russell wrote:
If we fail to transmit a packet, we assume the queue is full and put
the skb into last_xmit_skb. However, if more space
next-20080613 on x86_32 has lots of xen build errors like this:
linux-next-20080613/arch/x86/xen/mmu.c: In function 'drop_mm_ref':
linux-next-20080613/arch/x86/xen/mmu.c:759: error: implicit declaration of
function 'xen_smp_call_function_mask'
make[2]: *** [arch/x86/xen/mmu.o] Error 1
On Tue, Jun 10, 2008 at 4:46 PM, Glauber Costa [EMAIL PROTECTED] wrote:
If we're not gonna do anything (case in which failure is already
reported), we do not need to even bother with calculating the linear rip.
This is a nitpick, but I saw it while doing some testing, so here's
the patch.
On Fri, Jun 13, 2008 at 2:33 PM, Mohammed Gamal [EMAIL PROTECTED] wrote:
On Tue, Jun 10, 2008 at 4:46 PM, Glauber Costa [EMAIL PROTECTED] wrote:
If we're not gonna do anything (case in which failure is already
reported), we do not need to even bother with calculating the linear rip.
This is a
Glauber Costa wrote:
unsigned long rip = vcpu-arch.rip;
unsigned long rip_linear;
- rip_linear = rip + get_segment_base(vcpu, VCPU_SREG_CS);
-
if (reported)
return;
+ rip_linear = rip + get_segment_base(vcpu, VCPU_SREG_CS);
+
Mark McLoughlin wrote:
On Thu, 2008-05-29 at 16:34 +1000, Rusty Russell wrote:
On Tuesday 27 May 2008 21:06:26 Mark McLoughlin wrote:
On Mon, 2008-05-26 at 17:42 +1000, Rusty Russell wrote:
If we fail to transmit a packet, we assume the queue is full and put
the skb into last_xmit_skb.
Randy Dunlap wrote:
next-20080613 on x86_32 has lots of xen build errors like this:
linux-next-20080613/arch/x86/xen/mmu.c: In function 'drop_mm_ref':
linux-next-20080613/arch/x86/xen/mmu.c:759: error: implicit declaration of
function 'xen_smp_call_function_mask'
make[2]: *** [arch/x86/xen
Glauber Costa wrote:
I've changed it to use printk_ratelimit().
I've tested this option here before sending out the patch, since it
would address all issues.
But in error cases, it still seemed to generate too many messages.
Isn't that a bug in printk_ratelimit(), then?
--
I
On Fri, Jun 13, 2008 at 11:14 PM, Avi Kivity [EMAIL PROTECTED] wrote:
Glauber Costa wrote:
I've changed it to use printk_ratelimit().
I've tested this option here before sending out the patch, since it
would address all issues.
But in error cases, it still seemed to generate too many
On Friday 13 June 2008 22:46:40 Mark McLoughlin wrote:
Hook up to the probe() and remove() methods in bus_type
rather than device_driver. The latter has been preferred
since 2.6.16.
Signed-off-by: Mark McLoughlin [EMAIL PROTECTED]
Thanks, applied.
Cheers,
Rusty.
On Friday 13 June 2008 22:46:41 Mark McLoughlin wrote:
lguest (in rusty's use-tun-ringfd patch) assumes that the
guest has updated its feature bits before setting its status
to VIRTIO_CONFIG_S_DRIVER_OK.
That's pretty reasonable, so let's make it so.
Applied. That's a bug, I'll send to
Glauber Costa wrote:
I don't think so. It wasn't enough messages to DoS the system.
Just enough messages to annoy me.
If emulation failure messages annoy you, I'm sure you can think of a way
of removing them other than tampering with kvm_report_emulation_failure().
--
I have a truly
13 matches
Mail list logo
