On Wed, 18 Jun 2008 22:08:08 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
wrote:
>
> Randy Dunlap wrote:
> > linux-next-20080618/drivers/xen/manage.c: In function 'xen_suspend':
> > linux-next-20080618/drivers/xen/manage.c:66: error: too few arguments to
> &
Randy Dunlap wrote:
> linux-next-20080618/drivers/xen/manage.c: In function 'xen_suspend':
> linux-next-20080618/drivers/xen/manage.c:66: error: too few arguments to
> function 'device_power_up'
> linux-next-20080618/drivers/xen/manage.c: In function 'do_su
Benjamin Herrenschmidt wrote:
> On Wed, 2008-06-18 at 17:24 -0700, Linus Torvalds wrote:
>
>> On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
>>
>>> Along the lines of:
>>>
>> Hell no. There's a reason we have a special set_wrprotect() thing. We can
>> do it more efficiently on nati
On Wed, 18 Jun 2008, Linus Torvalds wrote:
>
> And yes, the "lock andl" should be noticeably faster than the xchgl.
I dunno. Here's a untested (!!) patch that turns constant-bit
set/clear_bit ops into byte mask ops (lock orb/andb).
It's not exactly pretty. The reason for using the byte versio
Hi, Tony
>> Resolve it by increasing NET_SKB_NET from the default value 16 to 18.
>
>Typo? You mean NET_SKB_PAD here?
>
I think so. :-)
>But in include/linux/skbuff.h it says: "It must be a power of 2".
>
>Explain why 18 is ok.
It's supposed to add NET_IP_ALIGN when network driver allocs
skb wi
On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
>
> It's not cmpxchg, just xchg.
> In other words, is:
>
> lock btr $_PAGE_BIT_RW, (%rbx)
Well, we can actually do it as
lock andl $~_PAGE_RW,(%rbx)
although we haven't bothered (I've wanted several times to make
clear_bit() do t
On Wed, 2008-06-18 at 17:24 -0700, Linus Torvalds wrote:
>
> On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
> >
> > Along the lines of:
>
> Hell no. There's a reason we have a special set_wrprotect() thing. We can
> do it more efficiently on native hardware by just clearing the bit
> atomicall
Rusty Russell wrote:
> We force notification when the ring is full, even if the host has
> indicated it doesn't want to know. This seemed like a good idea at
> the time: if we fill the transmit ring, we should tell the host
> immediately.
>
> Unfortunately this logic also applies to the receiving
Linus Torvalds wrote:
> On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
>
>> Along the lines of:
>>
>
> Hell no. There's a reason we have a special set_wrprotect() thing. We can
> do it more efficiently on native hardware by just clearing the bit
> atomically. No need to do the cmpxchg ga
On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
>
> Along the lines of:
Hell no. There's a reason we have a special set_wrprotect() thing. We can
do it more efficiently on native hardware by just clearing the bit
atomically. No need to do the cmpxchg games.
Linus
_
Jeremy Fitzhardinge wrote:
> Benjamin Herrenschmidt wrote:
>
>> On Mon, 2008-06-16 at 04:30 -0700, Jeremy Fitzhardinge wrote:
>>
>>
>>> The only current user of this interface is mprotect
>>>
>>>
>> Do you plan to use it with fork ultimately ?
>>
>>
>
> Good point, I'
Benjamin Herrenschmidt wrote:
> On Mon, 2008-06-16 at 04:30 -0700, Jeremy Fitzhardinge wrote:
>
>> The only current user of this interface is mprotect
>>
>
> Do you plan to use it with fork ultimately ?
>
Good point, I'd overlooked that. I guess that means using it in
ptep_set_wrprote
We force notification when the ring is full, even if the host has
indicated it doesn't want to know. This seemed like a good idea at
the time: if we fill the transmit ring, we should tell the host
immediately.
Unfortunately this logic also applies to the receiving ring, which is
refilled constant
On Mon, 2008-06-16 at 04:30 -0700, Jeremy Fitzhardinge wrote:
>
> The only current user of this interface is mprotect
Do you plan to use it with fork ultimately ?
Ben.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://
> introduce CONFIG_PARAVIRT_GUEST, CONFIG_PARAVIRT for
> paravirtualized guest.
> introduce CONFING_XEN, CONFIG_IA64_XEN for xen.
s/CONFING_XEN/CONFIG_XEN/
Would it make sense to rename CONFIG_IA64_XEN to be
CONFIG_IA64_XEN_GUEST? The comments you add to
arch/ia64/Kconfig say that this is what i
> This patch includes ia64 counter part of
> 9e124fe16ff24746d6de5a2ad685266d7bce0e08 and
> 83abc70a4c6e306f4c1672e25884322f797e4fcb for xen early printk support.
These GIT commit ids do not exist in Linus' tree, so this
is not a good commit log message.
-Tony
> On ia64/xen, pointer arguments for hypercall is passed
> by pseudo physical address(guest physical address.)
> So such hypercalls needs address conversion functions.
> This patch implements concreate conversion functions for
s/concreate/concrete/
-Tony
___
> On ia64/xen, pointer argument for the hypercall is passed
> by pseudo physical address (guest phsysical address.)
s/phsysical/physical/
> So it is necessary to convert virtual address into pseudo physical
> address rigth before issuing hypercall. The frame work is called
s/rigth/right/
+#ifde
linux-next-20080618/drivers/xen/manage.c: In function 'xen_suspend':
linux-next-20080618/drivers/xen/manage.c:66: error: too few arguments to
function 'device_power_up'
linux-next-20080618/drivers/xen/manage.c: In function 'do_suspend':
linux-next-20080618/drivers/xe
19 matches
Mail list logo
