* Kernel 2.6.32-5-amd64 fails to boot.
From: Leslie Rhorer @ 2011-02-01 20:23 UTC (permalink / raw)
To: 'Linux RAID'
I have been attempting to upgrade a Debian "Squeeze" Linux box from
2.6.32-3-amd64 to 2.6.32-5-amd64, but the upgrade is a non-starter. GRUB2
comes up just fine, but when I select the new kernel version, a number of
announcements flash by too fast to seen. I am not 100% certain, but I
believe the initrd starts to load OK. Some text flies by far too quickly to
be seen, but then an error pops up concerning an address space collision of
some PCI device. Then it shows three errors for RAID devices md1. md2, and
md3, saying they are already in use. Immediately thereafter the system shows
errors concerning the RAID targets being already in use, after which point
the system complains it can't mount / (md2), /dev, /sys, or /proc (in that
order) because the sources do not exist (if /dev/md2 does not exist, how can
it be busy?). Thereafter, of course, it fails to find init, since / is not
mounted. It then tries to run BusyBox, but Busybox complains:
/bin/sh: can't access tty; job control turned off
After that, it attempts to put up an initramfs prompt, but of course with no
tty access, it just hangs completely. Not surprisingly, recovery mode
doesn't boot, either. It gives a bit more detail in the output, but nothing
illuminating. The old kernel (2.6.32-3-amd64) boots just fine.
Obviously there is a problem in the initramfs, probably with mdadm, but
what? What should I try to manipulate in the initrd so I can find out what
is failing?
^ permalink raw reply
* Re: [1.8.0] forbid full fetchspecs in git-pull
From: Dmitry Potapov @ 2011-02-01 20:23 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git, Sean Estabrooks, Björn Steinbrink
In-Reply-To: <201102011614.57366.trast@student.ethz.ch>
On Tue, Feb 01, 2011 at 04:14:57PM +0100, Thomas Rast wrote:
> Dmitry Potapov wrote:
> > As to disallowing ':' in refspec completely, I am not so sure... Not
> > that I think it is very useful, but also I don't see how it can hurt
> > someone provided that the target branch cannot be the current branch.
>_
> IRC experience shows that people, while on some topic branch, run
>_
> git pull origin master:master
>_
> expecting it to "pull master into master" (or even worse with three
> different branch names). So no, the current branch safeguard does
> not prevent the fundamental mistake.
I am not sure what you mean by three different branches names. You
referred to item 1, and I agree it is confusing, but it can be prevented
by the current branch safeguard.
and the current semantic of "git pull" is very clear:
"git pull repo refspec" = "git fetch repo refspec && git merge FETCH_HEAD"
IMHO, the full confusion was caused by incorrect information on github,
which was corrected a long time ago. Have you heard about any new
users who are confused by git-pull?
And if we really want to disallow ':' in git pull refspec then the
documentation should be corrected too. For instance, if there are
options to git fetch that make no sense if you cannot specify lbranch.
Also description of refspec should be corrected in git pull man page.
Dmitry
^ permalink raw reply
* [GIT PULL] staging: tidspbridge for 2.6.39
From: Omar Ramirez Luna @ 2011-02-01 20:13 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Omar Ramirez Luna, Felipe Contreras, lk, devel
The following changes since commit c56eb8fb6dccb83d9fe62fd4dc00c834de9bc470:
Linux 2.6.38-rc1 (2011-01-18 15:14:02 -0800)
are available in the git repository at:
git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git tidspbridge-for-2.6.39
Armando Uribe (6):
staging: tidspbridge: Eliminate direct manipulation of OMAP_SYSC_BASE
staging: tidspbridge: Remove unused defined constants
staging: tidspbridge: Remove unused functions
staging: tidspbridge: Remove unused structs
staging: tidspbridge: Remove unused typedefs
staging: tidspbridge: Remove trivial header files
Felipe Contreras (1):
staging: tidspbridge: fix mgr_enum_node_info
Guzman Lugo, Fernando (2):
staging: tidspbridge: configure full L1 MMU range
staging: tidspbridge: make sync_wait_on_event interruptible
Ionut Nicu (13):
staging: tidspbridge: mgr_enum_node_info cleanup
staging: tidspbridge: fix kernel oops in bridge_io_get_proc_load
staging: tidspbridge: remove gs memory allocator
staging: tidspbridge: remove utildefs
staging: tidspbridge: switch to linux bitmap API
staging: tidspbridge: remove gb bitmap implementation
staging: tidspbridge: convert core to list_head
staging: tidspbridge: convert pmgr to list_head
staging: tidspbridge: convert rmgr to list_head
staging: tidspbridge: remove custom linked list
staging: tidspbridge: core code cleanup
staging: tidspbridge: pmgr code cleanup
staging: tidspbridge: rmgr/node.c code cleanup
Laurent Pinchart (1):
staging: tidspbridge: Fix atoi to support hexadecimal numbers correctly
Omar Ramirez Luna (2):
staging: tidspbridge: replace mbox callback with notifier_call
staging: tidspbridge: use the right type for list_is_last
Ramos Falcon, Ernesto (1):
staging: tidspbridge: remove code referred by OPT_ZERO_COPY_LOADER
Rene Sapiens (12):
staging: tidspbridge: set1 remove hungarian from structs
staging: tidspbridge: set2 remove hungarian from structs
staging: tidspbridge: set3 remove hungarian from structs
staging: tidspbridge: set4 remove hungarian from structs
staging: tidspbridge: set5 remove hungarian from structs
staging: tidspbridge: set6 remove hungarian from structs
staging: tidspbridge: set7 remove hungarian from structs
staging: tidspbridge: set8 remove hungarian from structs
staging: tidspbridge: set9 remove hungarian from structs
staging: tidspbridge: set10 remove hungarian from structs
staging: tidspbridge: set11 remove hungarian from structs
staging: tidspbridge: set12 remove hungarian from structs
Sapiens, Rene (1):
staging: tidspbridge: overwrite DSP error codes
drivers/staging/tidspbridge/Makefile | 2 +-
drivers/staging/tidspbridge/TODO | 1 -
drivers/staging/tidspbridge/core/_deh.h | 2 +-
drivers/staging/tidspbridge/core/_msg_sm.h | 16 +-
drivers/staging/tidspbridge/core/_tiomap.h | 30 +-
drivers/staging/tidspbridge/core/chnl_sm.c | 676 ++++++-------
drivers/staging/tidspbridge/core/dsp-clock.c | 52 +-
drivers/staging/tidspbridge/core/io_sm.c | 680 ++++++-------
drivers/staging/tidspbridge/core/msg_sm.c | 619 +++++-------
drivers/staging/tidspbridge/core/tiomap3430.c | 214 ++--
drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 112 +-
drivers/staging/tidspbridge/core/tiomap_io.c | 96 +-
drivers/staging/tidspbridge/core/ue_deh.c | 28 +-
drivers/staging/tidspbridge/dynload/cload.c | 102 +--
.../staging/tidspbridge/dynload/dload_internal.h | 6 +-
drivers/staging/tidspbridge/gen/gb.c | 166 ---
drivers/staging/tidspbridge/gen/gh.c | 38 +-
drivers/staging/tidspbridge/gen/gs.c | 88 --
drivers/staging/tidspbridge/gen/uuidutil.c | 22 +-
.../tidspbridge/include/dspbridge/_chnl_sm.h | 26 +-
.../tidspbridge/include/dspbridge/brddefs.h | 2 -
.../tidspbridge/include/dspbridge/cfgdefs.h | 50 +-
.../staging/tidspbridge/include/dspbridge/chnl.h | 21 -
.../tidspbridge/include/dspbridge/chnldefs.h | 9 +-
.../tidspbridge/include/dspbridge/chnlpriv.h | 21 +-
.../staging/tidspbridge/include/dspbridge/cmm.h | 2 +-
.../tidspbridge/include/dspbridge/cmmdefs.h | 39 +-
.../staging/tidspbridge/include/dspbridge/cod.h | 13 +-
.../tidspbridge/include/dspbridge/dbdcddef.h | 14 +-
.../staging/tidspbridge/include/dspbridge/dbdefs.h | 98 +--
.../tidspbridge/include/dspbridge/dbldefs.h | 141 ---
.../staging/tidspbridge/include/dspbridge/dbll.h | 6 -
.../tidspbridge/include/dspbridge/dblldefs.h | 65 --
.../tidspbridge/include/dspbridge/dehdefs.h | 32 -
.../staging/tidspbridge/include/dspbridge/dev.h | 65 +--
.../staging/tidspbridge/include/dspbridge/disp.h | 15 +-
.../tidspbridge/include/dspbridge/dispdefs.h | 35 -
.../staging/tidspbridge/include/dspbridge/drv.h | 40 +-
.../tidspbridge/include/dspbridge/drvdefs.h | 25 -
.../tidspbridge/include/dspbridge/dspapi-ioctl.h | 216 ++--
.../tidspbridge/include/dspbridge/dspdefs.h | 88 +-
.../staging/tidspbridge/include/dspbridge/dspdrv.h | 2 -
.../staging/tidspbridge/include/dspbridge/dspio.h | 4 +-
.../tidspbridge/include/dspbridge/dspioctl.h | 13 +-
.../tidspbridge/include/dspbridge/dynamic_loader.h | 2 -
drivers/staging/tidspbridge/include/dspbridge/gb.h | 79 --
drivers/staging/tidspbridge/include/dspbridge/gs.h | 59 --
.../tidspbridge/include/dspbridge/host_os.h | 9 -
drivers/staging/tidspbridge/include/dspbridge/io.h | 29 +-
.../staging/tidspbridge/include/dspbridge/io_sm.h | 164 +---
.../staging/tidspbridge/include/dspbridge/iodefs.h | 36 -
.../staging/tidspbridge/include/dspbridge/ldr.h | 29 -
.../staging/tidspbridge/include/dspbridge/list.h | 225 ----
.../staging/tidspbridge/include/dspbridge/mbx_sh.h | 40 -
.../tidspbridge/include/dspbridge/mgrpriv.h | 4 +-
.../tidspbridge/include/dspbridge/nldrdefs.h | 24 +-
.../staging/tidspbridge/include/dspbridge/node.h | 20 +-
.../tidspbridge/include/dspbridge/nodepriv.h | 10 +-
.../staging/tidspbridge/include/dspbridge/pwr.h | 8 +-
.../staging/tidspbridge/include/dspbridge/pwr_sh.h | 33 -
.../include/dspbridge/resourcecleanup.h | 11 -
.../staging/tidspbridge/include/dspbridge/rms_sh.h | 9 -
.../staging/tidspbridge/include/dspbridge/strm.h | 62 --
.../tidspbridge/include/dspbridge/strmdefs.h | 6 +-
.../staging/tidspbridge/include/dspbridge/sync.h | 14 +-
.../tidspbridge/include/dspbridge/utildefs.h | 39 -
drivers/staging/tidspbridge/pmgr/chnl.c | 4 +-
drivers/staging/tidspbridge/pmgr/cmm.c | 675 +++++-------
drivers/staging/tidspbridge/pmgr/cod.c | 20 +-
drivers/staging/tidspbridge/pmgr/dbll.c | 53 +-
drivers/staging/tidspbridge/pmgr/dev.c | 355 +++----
drivers/staging/tidspbridge/pmgr/dspapi.c | 272 +++---
drivers/staging/tidspbridge/pmgr/io.c | 9 +-
drivers/staging/tidspbridge/pmgr/ioobj.h | 4 +-
drivers/staging/tidspbridge/pmgr/msg.c | 4 +-
drivers/staging/tidspbridge/rmgr/dbdcd.c | 66 +-
drivers/staging/tidspbridge/rmgr/disp.c | 124 +--
drivers/staging/tidspbridge/rmgr/drv.c | 202 ++---
drivers/staging/tidspbridge/rmgr/drv_interface.c | 1 -
drivers/staging/tidspbridge/rmgr/mgr.c | 66 +-
drivers/staging/tidspbridge/rmgr/nldr.c | 117 +--
drivers/staging/tidspbridge/rmgr/node.c | 1092 +++++++++-----------
drivers/staging/tidspbridge/rmgr/proc.c | 170 ++--
drivers/staging/tidspbridge/rmgr/pwr.c | 8 +-
drivers/staging/tidspbridge/rmgr/rmm.c | 93 +--
drivers/staging/tidspbridge/rmgr/strm.c | 86 +-
86 files changed, 3028 insertions(+), 5297 deletions(-)
delete mode 100644 drivers/staging/tidspbridge/gen/gb.c
delete mode 100644 drivers/staging/tidspbridge/gen/gs.c
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dbldefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dehdefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dispdefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/drvdefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/gb.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/gs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/iodefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/ldr.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/list.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/pwr_sh.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/utildefs.h
Regards,
Omar
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-01 20:25 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: David Miller, steved, netdev, kvm
In-Reply-To: <20110201201715.GA30050@redhat.com>
On Tue, 2011-02-01 at 22:17 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 01, 2011 at 12:09:03PM -0800, Shirley Ma wrote:
> > On Tue, 2011-02-01 at 19:23 +0200, Michael S. Tsirkin wrote:
> > > On Thu, Jan 27, 2011 at 01:30:38PM -0800, Shirley Ma wrote:
> > > > On Thu, 2011-01-27 at 13:02 -0800, David Miller wrote:
> > > > > > Interesting. Could this is be a variant of the now famuous
> > > > > bufferbloat then?
> > > > >
> > > > > Sigh, bufferbloat is the new global warming... :-/
> > > >
> > > > Yep, some places become colder, some other places become warmer;
> > > Same as
> > > > BW results, sometimes faster, sometimes slower. :)
> > > >
> > > > Shirley
> > >
> > > Sent a tuning patch (v2) that might help.
> > > Could you try it and play with the module parameters please?
> >
> > Hello Michael,
> >
> > Sure I will play with this patch to see how it could help.
> >
> > I am looking at guest side as well, I found a couple issues on guest
> > side:
> >
> > 1. free_old_xmit_skbs() should return the number of skbs instead of
> the
> > total of sgs since we are using ring size to stop/start netif queue.
> > static unsigned int free_old_xmit_skbs(struct virtnet_info *vi)
> > {
> > struct sk_buff *skb;
> > unsigned int len, tot_sgs = 0;
> >
> > while ((skb = virtqueue_get_buf(vi->svq, &len)) != NULL) {
> > pr_debug("Sent skb %p\n", skb);
> > vi->dev->stats.tx_bytes += skb->len;
> > vi->dev->stats.tx_packets++;
> > tot_sgs += skb_vnet_hdr(skb)->num_sg;
> > dev_kfree_skb_any(skb);
> > }
> > return tot_sgs; <---- should return numbers of skbs to track
> > ring usage here, I think;
> > }
> >
> > Did the old guest use number of buffers to track ring usage before?
> >
> > 2. In start_xmit, I think we should move capacity +=
> free_old_xmit_skbs
> > before netif_stop_queue(); so we avoid unnecessary netif queue
> > stop/start. This condition is heavily hit for small message size.
> >
> > Also we capacity checking condition should change to something like
> half
> > of the vring.num size, instead of comparing 2+MAX_SKB_FRAGS?
> >
> > if (capacity < 2+MAX_SKB_FRAGS) {
> > netif_stop_queue(dev);
> > if (unlikely(!virtqueue_enable_cb(vi->svq))) {
> > /* More just got used, free them then
> recheck.
> > */
> > capacity += free_old_xmit_skbs(vi);
> > if (capacity >= 2+MAX_SKB_FRAGS) {
> > netif_start_queue(dev);
> > virtqueue_disable_cb(vi->svq);
> > }
> > }
> > }
> >
> > 3. Looks like the xmit callback is only used to wake the queue when
> the
> > queue has stopped, right? Should we put a condition check here?
> > static void skb_xmit_done(struct virtqueue *svq)
> > {
> > struct virtnet_info *vi = svq->vdev->priv;
> >
> > /* Suppress further interrupts. */
> > virtqueue_disable_cb(svq);
> >
> > /* We were probably waiting for more output buffers. */
> > ---> if (netif_queue_stopped(vi->dev))
> > netif_wake_queue(vi->dev);
> > }
> >
> >
> > Shirley
>
> Well the return value is used to calculate capacity and that counts
> the # of s/g. No?
Nope, the current guest kernel uses descriptors not number of sgs. I am
not sure the old guest.
> From cache utilization POV it might be better to read from the skb and
> not peek at virtio header though...
> Pls Cc the lists on any discussions in the future.
>
> --
> MST
Sorry I missed reply all. :(
Shirley
^ permalink raw reply
* Re: Selecting multiple radio access technologies in oFono
From: Aki Niemi @ 2011-02-01 20:25 UTC (permalink / raw)
To: ofono
In-Reply-To: <4D46C032.60405@tieto.com>
[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]
Hi Paavo,
On Mon, 2011-01-31 at 15:59 +0200, ext Paavo Leinonen wrote:
> Could it be possible to extend current TechnologyPreference setting in
> radio-settings-api in a way which would enable user to limit usage of
> certain
> radio accesses? For example user could choose to limit technology usage to
> technologies like GSM and UMTS even if the LTE coverage would be available.
> Following value could be introduced to current API to enable this kind of
> selection:
>
> "gsm" Only GSM used for radio access.
> "umts" Only UMTS used for radio access.
> "gsm_umts" Only GSM or UMTS used for radio access.
> "lte" Only LTE used for radio access.
The current API has 'gsm', 'umts', 'lte' and 'any'. I think you are
suggesting something like 'all-but-lte', right?
> Other approach could be that we would rephrase existing API so that
> instead of
> using "only" LTE, we would use LTE whenever available and some older
> technology
> when LTE coverage is lacking. So user would select "highest" allowed radio
> access without restrictions to use only one technology which has been
> selected.
This is what 'any' essentially is for.
> This would save us from polluting value selection with options like
> "gsm_umts",
> a decision we'd be grateful when we'll run oFono on 10G modems. ;)
>
> Use case for this could be energy conservation. At least I have habit to set
> network preference to 'GSM' to conserve battery life when I know I'm
> going to
> travel places where 3G coverage is not that good or I'm not going to
> need it.
I think this will also get gradually better as networks and handsets are
upgraded to use better power saving features, such as CPC.
Cheers,
Aki
> Br,
> Paavo
>
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono
^ permalink raw reply
* Re: [PATCH] make tsc stable over migration and machine start
From: Jan Kiszka @ 2011-02-01 20:26 UTC (permalink / raw)
To: Glauber Costa; +Cc: kvm, qemu-devel, avi, mtosatti
In-Reply-To: <1296587851-19621-1-git-send-email-glommer@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2761 bytes --]
On 2011-02-01 20:17, Glauber Costa wrote:
> If the machine is stopped, we should not record two different tsc values
> upon a save operation. The same problem happens with kvmclock.
>
> But kvmclock is taking a different diretion, being now seen as a separate
> device. Since this is unlikely to happen with the tsc, I am taking the
> approach here of simply registering a handler for state change, and
> using a per-CPUState variable that prevents double updates for the TSC.
>
> Signed-off-by: Glauber Costa <glommer@redhat.com>
> ---
> target-i386/cpu.h | 1 +
> target-i386/kvm.c | 19 ++++++++++++++++++-
> 2 files changed, 19 insertions(+), 1 deletions(-)
>
> diff --git a/target-i386/cpu.h b/target-i386/cpu.h
> index 6d619e8..7f1c4f8 100644
> --- a/target-i386/cpu.h
> +++ b/target-i386/cpu.h
> @@ -732,6 +732,7 @@ typedef struct CPUX86State {
> uint32_t sipi_vector;
> uint32_t cpuid_kvm_features;
> uint32_t cpuid_svm_features;
> + uint8_t update_tsc;
bool please.
>
> /* in order to simplify APIC support, we leave this pointer to the
> user */
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index ecb8405..c3925be 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -302,6 +302,16 @@ void kvm_inject_x86_mce(CPUState *cenv, int bank, uint64_t status,
>
> static int _kvm_arch_init_vcpu(CPUState *env);
>
> +static void cpu_update_state(void *opaque, int running, int reason)
> +{
> + CPUState *env = opaque;
> +
> + if (!running) {
> + env->update_tsc = 1;
> + }
> +}
> +
> +
Additional blank line.
> int kvm_arch_init_vcpu(CPUState *env)
> {
> int r;
> @@ -444,6 +454,8 @@ int kvm_arch_init_vcpu(CPUState *env)
> }
> #endif
>
> + qemu_add_vm_change_state_handler(cpu_update_state, env);
> +
> return kvm_vcpu_ioctl(env, KVM_SET_CPUID2, &cpuid_data);
> }
>
> @@ -1093,7 +1105,12 @@ static int kvm_get_msrs(CPUState *env)
> msrs[n++].index = MSR_STAR;
> if (kvm_has_msr_hsave_pa(env))
> msrs[n++].index = MSR_VM_HSAVE_PA;
> - msrs[n++].index = MSR_IA32_TSC;
> +
> + if (env->update_tsc) {
> + msrs[n++].index = MSR_IA32_TSC;
> + env->update_tsc = 0;
> + }
> +
> #ifdef TARGET_X86_64
> if (lm_capable_kernel) {
> msrs[n++].index = MSR_CSTAR;
Not quite the logic I'm using for kvmclock:
cpu_update_state()
if running
tsc_valid = false;
kvm_get_msrs()
...
if (!tsc_valid)
read_tsc
tsc_valid = !vm_running;
That ensure we always read the tsc while the VM is running, and not only
after it was stopped (might otherwise be "surprising" when once
visualizing the MSRs).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* [Qemu-devel] Re: [PATCH] make tsc stable over migration and machine start
From: Jan Kiszka @ 2011-02-01 20:26 UTC (permalink / raw)
To: Glauber Costa; +Cc: mtosatti, qemu-devel, kvm, avi
In-Reply-To: <1296587851-19621-1-git-send-email-glommer@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2761 bytes --]
On 2011-02-01 20:17, Glauber Costa wrote:
> If the machine is stopped, we should not record two different tsc values
> upon a save operation. The same problem happens with kvmclock.
>
> But kvmclock is taking a different diretion, being now seen as a separate
> device. Since this is unlikely to happen with the tsc, I am taking the
> approach here of simply registering a handler for state change, and
> using a per-CPUState variable that prevents double updates for the TSC.
>
> Signed-off-by: Glauber Costa <glommer@redhat.com>
> ---
> target-i386/cpu.h | 1 +
> target-i386/kvm.c | 19 ++++++++++++++++++-
> 2 files changed, 19 insertions(+), 1 deletions(-)
>
> diff --git a/target-i386/cpu.h b/target-i386/cpu.h
> index 6d619e8..7f1c4f8 100644
> --- a/target-i386/cpu.h
> +++ b/target-i386/cpu.h
> @@ -732,6 +732,7 @@ typedef struct CPUX86State {
> uint32_t sipi_vector;
> uint32_t cpuid_kvm_features;
> uint32_t cpuid_svm_features;
> + uint8_t update_tsc;
bool please.
>
> /* in order to simplify APIC support, we leave this pointer to the
> user */
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index ecb8405..c3925be 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -302,6 +302,16 @@ void kvm_inject_x86_mce(CPUState *cenv, int bank, uint64_t status,
>
> static int _kvm_arch_init_vcpu(CPUState *env);
>
> +static void cpu_update_state(void *opaque, int running, int reason)
> +{
> + CPUState *env = opaque;
> +
> + if (!running) {
> + env->update_tsc = 1;
> + }
> +}
> +
> +
Additional blank line.
> int kvm_arch_init_vcpu(CPUState *env)
> {
> int r;
> @@ -444,6 +454,8 @@ int kvm_arch_init_vcpu(CPUState *env)
> }
> #endif
>
> + qemu_add_vm_change_state_handler(cpu_update_state, env);
> +
> return kvm_vcpu_ioctl(env, KVM_SET_CPUID2, &cpuid_data);
> }
>
> @@ -1093,7 +1105,12 @@ static int kvm_get_msrs(CPUState *env)
> msrs[n++].index = MSR_STAR;
> if (kvm_has_msr_hsave_pa(env))
> msrs[n++].index = MSR_VM_HSAVE_PA;
> - msrs[n++].index = MSR_IA32_TSC;
> +
> + if (env->update_tsc) {
> + msrs[n++].index = MSR_IA32_TSC;
> + env->update_tsc = 0;
> + }
> +
> #ifdef TARGET_X86_64
> if (lm_capable_kernel) {
> msrs[n++].index = MSR_CSTAR;
Not quite the logic I'm using for kvmclock:
cpu_update_state()
if running
tsc_valid = false;
kvm_get_msrs()
...
if (!tsc_valid)
read_tsc
tsc_valid = !vm_running;
That ensure we always read the tsc while the VM is running, and not only
after it was stopped (might otherwise be "surprising" when once
visualizing the MSRs).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] Re: KVM call minutes for Feb 1
From: Anthony Liguori @ 2011-02-01 20:28 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Chris Wright, qemu-devel@nongnu.org, kvm@vger.kernel.org
In-Reply-To: <4D48443A.80108@siemens.com>
On 02/01/2011 11:34 AM, Jan Kiszka wrote:
> On 2011-02-01 18:20, Anthony Liguori wrote:
>
>> On 02/01/2011 11:03 AM, Jan Kiszka wrote:
>>
>>> On 2011-02-01 17:53, Anthony Liguori wrote:
>>>
>>>
>>>> On 02/01/2011 10:36 AM, Jan Kiszka wrote:
>>>>
>>>>
>>>>> On 2011-02-01 16:54, Chris Wright wrote:
>>>>>
>>>>>
>>>>>
>>>>>> KVM upstream merge: status, plans, coordination
>>>>>> - Jan has a git tree, consolidating
>>>>>> - qemu-kvm io threading is still an issue
>>>>>> - Anthony wants to just merge
>>>>>> - concerns with non-x86 arch and merge
>>>>>> - concerns with big-bang patch merge and following stability
>>>>>> - post 0.14 conversion to glib mainloop, non-upstreamed qemu-kvm will be
>>>>>> a problem if it's not there by then
>>>>>> - testing and nuances are still an issue (e.g. stefan berger's mmio read issue)
>>>>>> - qemu-kvm still evolving, needs to get sync'd or it will keep diverging
>>>>>> - 2 implementations of main init, cpu init, Jan has merged them into one
>>>>>> - qemu-kvm-x86.c file that's only a few hundred lines
>>>>>> - review as one patch to see the fundamental difference
>>>>>>
>>>>>>
>>>>>>
>>>>> More precisely, my current work flow is to pick some function(s), e.g.
>>>>> kvm_cpu_exec/kvm_run, and start wondering "What needs to be done to
>>>>> upstream so that qemu-kvm could use that implementation?". If they
>>>>> differ, the reasons need to be understood and patched away, either by
>>>>> fixing/enhancing upstream or simplifying qemu-kvm. Once the upstream
>>>>> changes are merged back, a qemu-kvm patch is posted to switch to that
>>>>> version.
>>>>>
>>>>> Any help will be welcome, either via review of my subtle regressions or
>>>>> on resolving concrete differences.
>>>>>
>>>>> E.g. posix-aio-compat.c: Why does qemu-kvm differ here? If it's because
>>>>> of its own iothread code, can we wrap that away or do we need to
>>>>> consolidate the threading code first? Or do we need to fix something in
>>>>> upstream?
>>>>>
>>>>>
>>>>>
>>>> I bet it's the eventfd thing. It's arbitrary. If you've got a small
>>>> diff post your series, I'd be happy to take a look at it and see what I
>>>> can explain.
>>>>
>>>>
>>>>
>>> Looks like it's around signalfd and its emulation:
>>>
>>>
>> I really meant the compatfd thing.
>>
>> signalfd can't really be emulated properly so in upstream we switched to
>> a pipe() which Avi didn't like.
>>
>> But with glib, this all goes away anyway so we should just drop the
>> qemu-kvm changes and use the upstream version. Once we enable I/O
>> thread in qemu.git, we no longer need to use signals for I/O completion
>> which I think everyone would agree is a better solution.
>>
> Don't understand: If we do not need SIGIO for AIO emulation in threaded
> mode, why wasn't that stubbed out already?
Historically, we used posix-aio which only notifies completion based on
signals.
However, because of the signal/select race, there's nothing useful that
can be done in the signal handler. So we then added signalfd such that
we could poll the signal safely from the select loop.
However, signalfd cannot be emulated reliably which was the approach we
had been using since signalfd is only available in newer kernels. So we
switched to having the signal handler write to a pipe() which gives us
an fd based notification mechanism. While qemu.git made that change,
qemu-kvm.git carried the signalfd version probably because we just
didn't argue about it enough back then.
Now, since we haven't used posix-aio in a very long time, there's really
no reason to go through this signal non-sense in the first place. We
can just make the helper threads write to a file descriptor (eventfd or
pipe). At one point, that's what we did in the tree. However, when TCG
does TB chaining, the only thing that will break a guest out of a tight
loop is a signal delivery. In single threaded TCG, if the guest doesn't
have a periodic timer enabled and issues an I/O operation, the
signalling is posix-aio-compat would break it out of the TB loop to let
it handle the completion. When we got rid of it, we broke these guests
with the symptom of I/Os not completing until you typed a key in the
serial console.
However, once we enable the I/O thread for TCG, the I/O thread can issue
a select() statement while the TCG thread is doing chaining. As long as
we send a signal to the TCG thread after select() returns and then wait
for qemu_mutex to be released, this problem doesn't exist anymore.
So enabling the I/O thread universally means we can drop signaling in
posix-aio.
Regards,
Anthony Liguori
> If that helps reducing
> worries about the signalfd emulation (which is likely a non-issue anyway
> as anyone with serious workload should run a kernel with such support).
>
> Jan
>
>
^ permalink raw reply
* Re: [PATCH v2] release kvmclock page on reset
From: Jan Kiszka @ 2011-02-01 20:28 UTC (permalink / raw)
To: Glauber Costa; +Cc: kvm, linux-kernel, aliguori
In-Reply-To: <1296587800-19589-1-git-send-email-glommer@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
On 2011-02-01 20:16, Glauber Costa wrote:
> When a vcpu is reset, kvmclock page keeps being writen to this days.
> This is wrong and inconsistent: a cpu reset should take it to its
> initial state.
>
> Signed-off-by: Glauber Costa <glommer@redhat.com>
> CC: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> arch/x86/kvm/x86.c | 20 ++++++++++++--------
> 1 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index bcc0efc..c39ab4a 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1453,6 +1453,14 @@ static int kvm_pv_enable_async_pf(struct kvm_vcpu *vcpu, u64 data)
> return 0;
> }
>
> +static void kvmclock_reset(struct kvm_vcpu *vcpu)
> +{
> + if (vcpu->arch.time_page) {
> + kvm_release_page_dirty(vcpu->arch.time_page);
> + vcpu->arch.time_page = NULL;
> + }
> +}
> +
> int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
> {
> switch (msr) {
> @@ -1510,10 +1518,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
> break;
> case MSR_KVM_SYSTEM_TIME_NEW:
> case MSR_KVM_SYSTEM_TIME: {
> - if (vcpu->arch.time_page) {
> - kvm_release_page_dirty(vcpu->arch.time_page);
> - vcpu->arch.time_page = NULL;
> - }
> + kvmclock_reset(vcpu);
>
> vcpu->arch.time = data;
> kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
> @@ -5814,10 +5819,7 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
>
> void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
> {
> - if (vcpu->arch.time_page) {
> - kvm_release_page_dirty(vcpu->arch.time_page);
> - vcpu->arch.time_page = NULL;
> - }
> + kvmclock_reset(vcpu);
>
> free_cpumask_var(vcpu->arch.wbinvd_dirty_mask);
> fx_free(vcpu);
> @@ -5878,6 +5880,8 @@ int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu)
> kvm_make_request(KVM_REQ_EVENT, vcpu);
> vcpu->arch.apf.msr_val = 0;
>
> + kvmclock_reset(vcpu);
> +
> kvm_clear_async_pf_completion_queue(vcpu);
> kvm_async_pf_hash_reset(vcpu);
> vcpu->arch.apf.halted = false;
Looks good.
Thanks,
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [PATCH] fs: make block fiemap mapping length at least blocksize long
From: Andrew Morton @ 2011-02-01 20:28 UTC (permalink / raw)
To: Steven Whitehouse; +Cc: Josef Bacik, linux-fsdevel
In-Reply-To: <1296560810.2586.12.camel@dolmen>
On Tue, 01 Feb 2011 11:46:50 +0000
Steven Whitehouse <swhiteho@redhat.com> wrote:
> On Wed, 2010-12-08 at 12:03 -0500, Josef Bacik wrote:
> > Some filesystems don't deal well with being asked to map less than blocksize
> > blocks (GFS2 for example). Since we are always mapping at least blocksize
> > sections anyway, just make sure len is at least as big as a blocksize so we
> > don't trip up any filesystems. Thanks,
> >
> > Signed-off-by: Josef Bacik <josef@redhat.com>
> > ---
> > fs/ioctl.c | 7 +++++++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/ioctl.c b/fs/ioctl.c
> > index d6cc164..6b53c24 100644
> > --- a/fs/ioctl.c
> > +++ b/fs/ioctl.c
> > @@ -273,6 +273,13 @@ int __generic_block_fiemap(struct inode *inode,
> > len = isize;
> > }
> >
> > + /*
> > + * Some filesystems can't deal with being asked to map less than
> > + * blocksize, so make sure our len is at least block length.
> > + */
> > + if (logical_to_blk(inode, len) == 0)
> > + len = blk_to_logical(inode, 1);
> > +
> > start_blk = logical_to_blk(inode, start);
> > last_blk = logical_to_blk(inode, start + len - 1);
> >
(top-posting repaired)
> Hi,
>
> Is there any reason this cannot be sent to Linus now?
>
I sent it to viro a couple of weeks back and it was ignored. I don't
know why this happens :(
^ permalink raw reply
* Re: [PATCH 11/11] xen/m2p: Check whether the MFN has IDENTITY_FRAME bit set..
From: Konrad Rzeszutek Wilk @ 2011-02-01 20:29 UTC (permalink / raw)
To: Stefano Stabellini
Cc: jeremy@goop.org, Xen-devel@lists.xensource.com,
linux-kernel@vger.kernel.org, Ian Campbell, konrad@kernel.org,
hpa@zytor.com
In-Reply-To: <alpine.DEB.2.00.1102011513190.7277@kaball-desktop>
On Tue, Feb 01, 2011 at 05:52:29PM +0000, Stefano Stabellini wrote:
> On Mon, 31 Jan 2011, Konrad Rzeszutek Wilk wrote:
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >
> > If we have the IDENTITY_FRAME bit set from the P2M, there
> > is no point in looking up MFN in the M2P override. This is
> > b/c the MFN is a physical MFN.
> >
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> > arch/x86/include/asm/xen/page.h | 8 +++++++-
> > 1 files changed, 7 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> > index ed46ec2..e6f7f37 100644
> > --- a/arch/x86/include/asm/xen/page.h
> > +++ b/arch/x86/include/asm/xen/page.h
> > @@ -81,6 +81,7 @@ static inline int phys_to_machine_mapping_valid(unsigned long pfn)
> > static inline unsigned long mfn_to_pfn(unsigned long mfn)
> > {
> > unsigned long pfn;
> > + unsigned long p2m_mfn;
> >
> > if (xen_feature(XENFEAT_auto_translated_physmap))
> > return mfn;
> > @@ -102,7 +103,12 @@ try_override:
> > * doesn't map back to the mfn), then check the local override
> > * table to see if there's a better pfn to use.
> > */
> > - if (get_phys_to_machine(pfn) != mfn)
> > + p2m_mfn = get_phys_to_machine(pfn);
> > +
> > + if (p2m_mfn == IDENTITY_FRAME(mfn))
> > + return pfn;
> > +
> > + if (p2m_mfn != mfn)
> > pfn = m2p_find_override_pfn(mfn, pfn);
> >
> > return pfn;
>
>
> I have been thinking some more about it and now I have few questions:
>
> 1) is it possible for a single domain to have a valid mfn with the same
> number as an identity mfn (apart from the IDENTITY_FRAME bit)?
Yes.
>
> 2) is it true that mfn_to_pfn should never be called passing an identity
> mfn (because we set _PAGE_IOMAP)?
Yes. And currently the code checks for _PAGE_IOMAP and bypasses the
M2P.
>
> 3) what is the value returned by m2p(identity_mfn)? Is it a correct pfn
> or may be something like 0xfffff or 0xeeeee?
0xFFFFF... or 0x5555555..
>
>
> These are my guessed answers:
>
> 1) yes, it is possible.
> For example mfn=0xc0100 might be a valid ram mfn present in the mfn_list
> of a domU and also be present as 1:1 mfn of the 3G-4G region.
If we consider it valid, then it would be in the E820 as an E820_RAM
type. The xen_setup_identity code would skip over that region and not
mark is as IDENTITY.
Keep in mind the code skips over small/big E820_RAM regions even if
those regions have reserved E820 regions on both sides.
> For this reason I think we should look in m2p_override first and check
> for possible identity mapping later.
> We might want to avoid these situations but the only way I can see to do
> it would be to make sure that the 1:1 regions are always subset of
> the host reserved regions, even for domUs.
Right, and they are...
>
> 2) yes indeed.
> One more reason to look in the m2p_override first.
Not sure I understand.
>
> 3) the returned pfn might be 0xfffff or 0xeeeee.
> We should use the mfn value directly as pfn value to check for possible
> identity mappings.
Aren't we doing that via 'get_phys_to_machine' ? It returns the value
and if it has the IDENTITY_FRAME_BIT it is an identity.
Or are you thinking of abolishing the IDENTITY_FRAME_BIT and check the
M2P in conjunction with the P2M to see if the mfn is a 1-1 mapping?
>
>
> The resulting patch looks like the following:
>
> ---
>
>
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index ed46ec2..7f9bae2 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -80,6 +80,7 @@ static inline int phys_to_machine_mapping_valid(unsigned long pfn)
>
> static inline unsigned long mfn_to_pfn(unsigned long mfn)
> {
> + int ret = 0;
> unsigned long pfn;
>
> if (xen_feature(XENFEAT_auto_translated_physmap))
> @@ -95,15 +96,21 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
> * In such cases it doesn't matter what we return (we return garbage),
> * but we must handle the fault without crashing!
> */
> - __get_user(pfn, &machine_to_phys_mapping[mfn]);
> + ret = __get_user(pfn, &machine_to_phys_mapping[mfn]);
> try_override:
> /*
> * If this appears to be a foreign mfn (because the pfn
> * doesn't map back to the mfn), then check the local override
> * table to see if there's a better pfn to use.
> */
> - if (get_phys_to_machine(pfn) != mfn)
> - pfn = m2p_find_override_pfn(mfn, pfn);
> + if (ret < 0)
> + pfn = ~0;
> + else if (get_phys_to_machine(pfn) != mfn)
> + pfn = m2p_find_override_pfn(mfn, ~0);
> +
> + if (pfn == ~0 &&
You should also check for 0x55555... then.
> + get_phys_to_machine(mfn) == IDENTITY_FRAME(mfn))
> + pfn = mfn;
So for identity type mfns we end up calling 'get_phys_to_machine(mfn)' twice
I think?
Would it make sense to save the result of 'get_phys_to_machine(mfn)'
the first call?
>
> return pfn;
> }
^ permalink raw reply
* Re: [PATCH] vxge: Fix wrong boolean operator {nodisc}
From: David Miller @ 2011-02-01 20:30 UTC (permalink / raw)
To: Ramkrishna.Vepa
Cc: weil, Sivakumar.Subramani, Sreenivasa.Honnur, netdev,
linux-kernel, Jon.Mason
In-Reply-To: <FCA91A92EE52B041906A0358FC28FCC38EFBE64996@FRE1EXCH02.hq.exar.com>
From: Ramkrishna Vepa <Ramkrishna.Vepa@exar.com>
Date: Mon, 31 Jan 2011 23:26:40 -0800
>> This error is reported by cppcheck:
>> drivers/net/vxge/vxge-config.c:3693: warning: Mutual exclusion over ||
>> always evaluates to true. Did you intend to use && instead?
>>
>> It looks like cppcheck is correct, so fix this. No test was run.
>>
>> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
...
> Fix looks good. Thanks!
>
> Acked-by: Ram Vepa <ram.vepa@exar.com>
Thanks for reviewing, applied.
^ permalink raw reply
* Re: [PATCH 11/11] xen/m2p: Check whether the MFN has IDENTITY_FRAME bit set..
From: Konrad Rzeszutek Wilk @ 2011-02-01 20:29 UTC (permalink / raw)
To: Stefano Stabellini
Cc: linux-kernel@vger.kernel.org, Xen-devel@lists.xensource.com,
konrad@kernel.org, jeremy@goop.org, hpa@zytor.com, Ian Campbell
In-Reply-To: <alpine.DEB.2.00.1102011513190.7277@kaball-desktop>
On Tue, Feb 01, 2011 at 05:52:29PM +0000, Stefano Stabellini wrote:
> On Mon, 31 Jan 2011, Konrad Rzeszutek Wilk wrote:
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >
> > If we have the IDENTITY_FRAME bit set from the P2M, there
> > is no point in looking up MFN in the M2P override. This is
> > b/c the MFN is a physical MFN.
> >
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> > arch/x86/include/asm/xen/page.h | 8 +++++++-
> > 1 files changed, 7 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> > index ed46ec2..e6f7f37 100644
> > --- a/arch/x86/include/asm/xen/page.h
> > +++ b/arch/x86/include/asm/xen/page.h
> > @@ -81,6 +81,7 @@ static inline int phys_to_machine_mapping_valid(unsigned long pfn)
> > static inline unsigned long mfn_to_pfn(unsigned long mfn)
> > {
> > unsigned long pfn;
> > + unsigned long p2m_mfn;
> >
> > if (xen_feature(XENFEAT_auto_translated_physmap))
> > return mfn;
> > @@ -102,7 +103,12 @@ try_override:
> > * doesn't map back to the mfn), then check the local override
> > * table to see if there's a better pfn to use.
> > */
> > - if (get_phys_to_machine(pfn) != mfn)
> > + p2m_mfn = get_phys_to_machine(pfn);
> > +
> > + if (p2m_mfn == IDENTITY_FRAME(mfn))
> > + return pfn;
> > +
> > + if (p2m_mfn != mfn)
> > pfn = m2p_find_override_pfn(mfn, pfn);
> >
> > return pfn;
>
>
> I have been thinking some more about it and now I have few questions:
>
> 1) is it possible for a single domain to have a valid mfn with the same
> number as an identity mfn (apart from the IDENTITY_FRAME bit)?
Yes.
>
> 2) is it true that mfn_to_pfn should never be called passing an identity
> mfn (because we set _PAGE_IOMAP)?
Yes. And currently the code checks for _PAGE_IOMAP and bypasses the
M2P.
>
> 3) what is the value returned by m2p(identity_mfn)? Is it a correct pfn
> or may be something like 0xfffff or 0xeeeee?
0xFFFFF... or 0x5555555..
>
>
> These are my guessed answers:
>
> 1) yes, it is possible.
> For example mfn=0xc0100 might be a valid ram mfn present in the mfn_list
> of a domU and also be present as 1:1 mfn of the 3G-4G region.
If we consider it valid, then it would be in the E820 as an E820_RAM
type. The xen_setup_identity code would skip over that region and not
mark is as IDENTITY.
Keep in mind the code skips over small/big E820_RAM regions even if
those regions have reserved E820 regions on both sides.
> For this reason I think we should look in m2p_override first and check
> for possible identity mapping later.
> We might want to avoid these situations but the only way I can see to do
> it would be to make sure that the 1:1 regions are always subset of
> the host reserved regions, even for domUs.
Right, and they are...
>
> 2) yes indeed.
> One more reason to look in the m2p_override first.
Not sure I understand.
>
> 3) the returned pfn might be 0xfffff or 0xeeeee.
> We should use the mfn value directly as pfn value to check for possible
> identity mappings.
Aren't we doing that via 'get_phys_to_machine' ? It returns the value
and if it has the IDENTITY_FRAME_BIT it is an identity.
Or are you thinking of abolishing the IDENTITY_FRAME_BIT and check the
M2P in conjunction with the P2M to see if the mfn is a 1-1 mapping?
>
>
> The resulting patch looks like the following:
>
> ---
>
>
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index ed46ec2..7f9bae2 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -80,6 +80,7 @@ static inline int phys_to_machine_mapping_valid(unsigned long pfn)
>
> static inline unsigned long mfn_to_pfn(unsigned long mfn)
> {
> + int ret = 0;
> unsigned long pfn;
>
> if (xen_feature(XENFEAT_auto_translated_physmap))
> @@ -95,15 +96,21 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
> * In such cases it doesn't matter what we return (we return garbage),
> * but we must handle the fault without crashing!
> */
> - __get_user(pfn, &machine_to_phys_mapping[mfn]);
> + ret = __get_user(pfn, &machine_to_phys_mapping[mfn]);
> try_override:
> /*
> * If this appears to be a foreign mfn (because the pfn
> * doesn't map back to the mfn), then check the local override
> * table to see if there's a better pfn to use.
> */
> - if (get_phys_to_machine(pfn) != mfn)
> - pfn = m2p_find_override_pfn(mfn, pfn);
> + if (ret < 0)
> + pfn = ~0;
> + else if (get_phys_to_machine(pfn) != mfn)
> + pfn = m2p_find_override_pfn(mfn, ~0);
> +
> + if (pfn == ~0 &&
You should also check for 0x55555... then.
> + get_phys_to_machine(mfn) == IDENTITY_FRAME(mfn))
> + pfn = mfn;
So for identity type mfns we end up calling 'get_phys_to_machine(mfn)' twice
I think?
Would it make sense to save the result of 'get_phys_to_machine(mfn)'
the first call?
>
> return pfn;
> }
^ permalink raw reply
* Re: [Qemu-devel] [PATCHv3 0.14] vhost: force vhost off for non-MSI guests
From: Anthony Liguori @ 2011-02-01 20:30 UTC (permalink / raw)
To: Michael S. Tsirkin, Alex Williamson
Cc: kvm, Juan Quintela, Jes.Sorensen, jasowang, qemu-devel
In-Reply-To: <20110201201342.GA30006@redhat.com>
On 02/01/2011 02:13 PM, Michael S. Tsirkin wrote:
> When MSI is off, each interrupt needs to be bounced through the io
> thread when it's set/cleared, so vhost-net causes more context switches and
> higher CPU utilization than userspace virtio which handles networking in
> the same thread.
>
> We'll need to fix this by adding level irq support in kvm irqfd,
> for now disable vhost-net in these configurations.
>
> Added a vhostforce flag to force vhost-net back on.
>
> Signed-off-by: Michael S. Tsirkin<mst@redhat.com>
>
This looks much nicer.
Regards,
Anthony Liguori
> ---
>
> OK this is 0.14 material so quick review would be appreciated.
> This version's compiled only, I'll naturally test more before I
> queue it.
>
> Changes from v2:
> get rid of EVIRTIO, add a separate API to query
> for fast guest notifiers
>
> Changes from v1:
> add vhostforce flag
>
> hw/vhost.c | 10 +++++++++-
> hw/vhost.h | 4 +++-
> hw/vhost_net.c | 24 ++++++++++++++++++------
> hw/vhost_net.h | 3 ++-
> hw/virtio-net.c | 6 +++++-
> hw/virtio-pci.c | 7 +++++++
> hw/virtio.h | 1 +
> net/tap.c | 6 ++++--
> qemu-options.hx | 4 +++-
> 9 files changed, 52 insertions(+), 13 deletions(-)
>
> diff --git a/hw/vhost.c b/hw/vhost.c
> index 6082da2..38cc3b3 100644
> --- a/hw/vhost.c
> +++ b/hw/vhost.c
> @@ -581,7 +581,7 @@ static void vhost_virtqueue_cleanup(struct vhost_dev *dev,
> 0, virtio_queue_get_desc_size(vdev, idx));
> }
>
> -int vhost_dev_init(struct vhost_dev *hdev, int devfd)
> +int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force)
> {
> uint64_t features;
> int r;
> @@ -613,6 +613,7 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd)
> hdev->log_enabled = false;
> hdev->started = false;
> cpu_register_phys_memory_client(&hdev->client);
> + hdev->force = force;
> return 0;
> fail:
> r = -errno;
> @@ -627,6 +628,13 @@ void vhost_dev_cleanup(struct vhost_dev *hdev)
> close(hdev->control);
> }
>
> +bool vhost_dev_query(struct vhost_dev *hdev, VirtIODevice *vdev)
> +{
> + return !vdev->binding->query_guest_notifiers ||
> + vdev->binding->query_guest_notifiers(vdev->binding_opaque) ||
> + hdev->force;
> +}
> +
> int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev)
> {
> int i, r;
> diff --git a/hw/vhost.h b/hw/vhost.h
> index 86dd834..c8c595a 100644
> --- a/hw/vhost.h
> +++ b/hw/vhost.h
> @@ -38,10 +38,12 @@ struct vhost_dev {
> bool log_enabled;
> vhost_log_chunk_t *log;
> unsigned long long log_size;
> + bool force;
> };
>
> -int vhost_dev_init(struct vhost_dev *hdev, int devfd);
> +int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force);
> void vhost_dev_cleanup(struct vhost_dev *hdev);
> +bool vhost_dev_query(struct vhost_dev *hdev, VirtIODevice *vdev);
> int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev);
> void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev);
>
> diff --git a/hw/vhost_net.c b/hw/vhost_net.c
> index c068be1..420e05f 100644
> --- a/hw/vhost_net.c
> +++ b/hw/vhost_net.c
> @@ -81,7 +81,8 @@ static int vhost_net_get_fd(VLANClientState *backend)
> }
> }
>
> -struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
> +struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd,
> + bool force)
> {
> int r;
> struct vhost_net *net = qemu_malloc(sizeof *net);
> @@ -98,7 +99,7 @@ struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
> (1<< VHOST_NET_F_VIRTIO_NET_HDR);
> net->backend = r;
>
> - r = vhost_dev_init(&net->dev, devfd);
> + r = vhost_dev_init(&net->dev, devfd, force);
> if (r< 0) {
> goto fail;
> }
> @@ -121,6 +122,11 @@ fail:
> return NULL;
> }
>
> +bool vhost_net_query(VHostNetState *net, VirtIODevice *dev)
> +{
> + return vhost_dev_query(&net->dev, dev);
> +}
> +
> int vhost_net_start(struct vhost_net *net,
> VirtIODevice *dev)
> {
> @@ -188,15 +194,21 @@ void vhost_net_cleanup(struct vhost_net *net)
> qemu_free(net);
> }
> #else
> -struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
> +struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd,
> + bool force)
> +{
> + return NULL;
> +}
> +
> +bool vhost_net_query(VHostNetState *net, VirtIODevice *dev)
> {
> - return NULL;
> + return false;
> }
>
> int vhost_net_start(struct vhost_net *net,
> VirtIODevice *dev)
> {
> - return -ENOSYS;
> + return -ENOSYS;
> }
> void vhost_net_stop(struct vhost_net *net,
> VirtIODevice *dev)
> @@ -209,7 +221,7 @@ void vhost_net_cleanup(struct vhost_net *net)
>
> unsigned vhost_net_get_features(struct vhost_net *net, unsigned features)
> {
> - return features;
> + return features;
> }
> void vhost_net_ack_features(struct vhost_net *net, unsigned features)
> {
> diff --git a/hw/vhost_net.h b/hw/vhost_net.h
> index 6c18ff7..91e40b1 100644
> --- a/hw/vhost_net.h
> +++ b/hw/vhost_net.h
> @@ -6,8 +6,9 @@
> struct vhost_net;
> typedef struct vhost_net VHostNetState;
>
> -VHostNetState *vhost_net_init(VLANClientState *backend, int devfd);
> +VHostNetState *vhost_net_init(VLANClientState *backend, int devfd, bool force);
>
> +bool vhost_net_query(VHostNetState *net, VirtIODevice *dev);
> int vhost_net_start(VHostNetState *net, VirtIODevice *dev);
> void vhost_net_stop(VHostNetState *net, VirtIODevice *dev);
>
> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> index ccb3e63..16ac103 100644
> --- a/hw/virtio-net.c
> +++ b/hw/virtio-net.c
> @@ -119,7 +119,11 @@ static void virtio_net_vhost_status(VirtIONet *n, uint8_t status)
> return;
> }
> if (!n->vhost_started) {
> - int r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer),&n->vdev);
> + int r;
> + if (!vhost_net_query(tap_get_vhost_net(n->nic->nc.peer),&n->vdev)) {
> + return;
> + }
> + r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer),&n->vdev);
> if (r< 0) {
> error_report("unable to start vhost net: %d: "
> "falling back on userspace virtio", -r);
> diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> index d07ff97..3911b09 100644
> --- a/hw/virtio-pci.c
> +++ b/hw/virtio-pci.c
> @@ -595,6 +595,12 @@ static int virtio_pci_set_guest_notifier(void *opaque, int n, bool assign)
> return 0;
> }
>
> +static bool virtio_pci_query_guest_notifiers(void *opaque)
> +{
> + VirtIOPCIProxy *proxy = opaque;
> + return msix_enabled(&proxy->pci_dev);
> +}
> +
> static int virtio_pci_set_guest_notifiers(void *opaque, bool assign)
> {
> VirtIOPCIProxy *proxy = opaque;
> @@ -658,6 +664,7 @@ static const VirtIOBindings virtio_pci_bindings = {
> .save_queue = virtio_pci_save_queue,
> .load_queue = virtio_pci_load_queue,
> .get_features = virtio_pci_get_features,
> + .query_guest_notifiers = virtio_pci_query_guest_notifiers,
> .set_host_notifier = virtio_pci_set_host_notifier,
> .set_guest_notifiers = virtio_pci_set_guest_notifiers,
> .vmstate_change = virtio_pci_vmstate_change,
> diff --git a/hw/virtio.h b/hw/virtio.h
> index d8546d5..31d16e1 100644
> --- a/hw/virtio.h
> +++ b/hw/virtio.h
> @@ -93,6 +93,7 @@ typedef struct {
> int (*load_config)(void * opaque, QEMUFile *f);
> int (*load_queue)(void * opaque, int n, QEMUFile *f);
> unsigned (*get_features)(void * opaque);
> + bool (*query_guest_notifiers)(void * opaque);
> int (*set_guest_notifiers)(void * opaque, bool assigned);
> int (*set_host_notifier)(void * opaque, int n, bool assigned);
> void (*vmstate_change)(void * opaque, bool running);
> diff --git a/net/tap.c b/net/tap.c
> index eada34a..b8cd252 100644
> --- a/net/tap.c
> +++ b/net/tap.c
> @@ -491,8 +491,10 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char *name, VLANState *vlan
> }
> }
>
> - if (qemu_opt_get_bool(opts, "vhost", !!qemu_opt_get(opts, "vhostfd"))) {
> + if (qemu_opt_get_bool(opts, "vhost", !!qemu_opt_get(opts, "vhostfd") ||
> + qemu_opt_get_bool(opts, "vhostforce", false))) {
> int vhostfd, r;
> + bool force = qemu_opt_get_bool(opts, "vhostforce", false);
> if (qemu_opt_get(opts, "vhostfd")) {
> r = net_handle_fd_param(mon, qemu_opt_get(opts, "vhostfd"));
> if (r == -1) {
> @@ -502,7 +504,7 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char *name, VLANState *vlan
> } else {
> vhostfd = -1;
> }
> - s->vhost_net = vhost_net_init(&s->nc, vhostfd);
> + s->vhost_net = vhost_net_init(&s->nc, vhostfd, force);
> if (!s->vhost_net) {
> error_report("vhost-net requested but could not be initialized");
> return -1;
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 898561d..11c93a2 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1050,7 +1050,7 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
> "-net tap[,vlan=n][,name=str],ifname=name\n"
> " connect the host TAP network interface to VLAN 'n'\n"
> #else
> - "-net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h]\n"
> + "-net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h][,vhostforce=on|off]\n"
> " connect the host TAP network interface to VLAN 'n' and use the\n"
> " network scripts 'file' (default=" DEFAULT_NETWORK_SCRIPT ")\n"
> " and 'dfile' (default=" DEFAULT_NETWORK_DOWN_SCRIPT ")\n"
> @@ -1061,6 +1061,8 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
> " use vnet_hdr=off to avoid enabling the IFF_VNET_HDR tap flag\n"
> " use vnet_hdr=on to make the lack of IFF_VNET_HDR support an error condition\n"
> " use vhost=on to enable experimental in kernel accelerator\n"
> + " (only has effect for virtio guests which use MSIX)\n"
> + " use vhostforce=on to force vhost on for non-MSIX virtio guests\n"
> " use 'vhostfd=h' to connect to an already opened vhost net device\n"
> #endif
> "-net socket[,vlan=n][,name=str][,fd=h][,listen=[host]:port][,connect=host:port]\n"
>
^ permalink raw reply
* Re: [PATCHv3 0.14] vhost: force vhost off for non-MSI guests
From: Alex Williamson @ 2011-02-01 20:30 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Anthony Liguori, kvm, Juan Quintela, Jes.Sorensen, jasowang,
qemu-devel
In-Reply-To: <20110201201342.GA30006@redhat.com>
On Tue, 2011-02-01 at 22:13 +0200, Michael S. Tsirkin wrote:
> When MSI is off, each interrupt needs to be bounced through the io
> thread when it's set/cleared, so vhost-net causes more context switches and
> higher CPU utilization than userspace virtio which handles networking in
> the same thread.
>
> We'll need to fix this by adding level irq support in kvm irqfd,
> for now disable vhost-net in these configurations.
>
> Added a vhostforce flag to force vhost-net back on.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> OK this is 0.14 material so quick review would be appreciated.
> This version's compiled only, I'll naturally test more before I
> queue it.
>
> Changes from v2:
> get rid of EVIRTIO, add a separate API to query
> for fast guest notifiers
I like this better. Thanks,
Alex
> Changes from v1:
> add vhostforce flag
>
> hw/vhost.c | 10 +++++++++-
> hw/vhost.h | 4 +++-
> hw/vhost_net.c | 24 ++++++++++++++++++------
> hw/vhost_net.h | 3 ++-
> hw/virtio-net.c | 6 +++++-
> hw/virtio-pci.c | 7 +++++++
> hw/virtio.h | 1 +
> net/tap.c | 6 ++++--
> qemu-options.hx | 4 +++-
> 9 files changed, 52 insertions(+), 13 deletions(-)
>
> diff --git a/hw/vhost.c b/hw/vhost.c
> index 6082da2..38cc3b3 100644
> --- a/hw/vhost.c
> +++ b/hw/vhost.c
> @@ -581,7 +581,7 @@ static void vhost_virtqueue_cleanup(struct vhost_dev *dev,
> 0, virtio_queue_get_desc_size(vdev, idx));
> }
>
> -int vhost_dev_init(struct vhost_dev *hdev, int devfd)
> +int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force)
> {
> uint64_t features;
> int r;
> @@ -613,6 +613,7 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd)
> hdev->log_enabled = false;
> hdev->started = false;
> cpu_register_phys_memory_client(&hdev->client);
> + hdev->force = force;
> return 0;
> fail:
> r = -errno;
> @@ -627,6 +628,13 @@ void vhost_dev_cleanup(struct vhost_dev *hdev)
> close(hdev->control);
> }
>
> +bool vhost_dev_query(struct vhost_dev *hdev, VirtIODevice *vdev)
> +{
> + return !vdev->binding->query_guest_notifiers ||
> + vdev->binding->query_guest_notifiers(vdev->binding_opaque) ||
> + hdev->force;
> +}
> +
> int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev)
> {
> int i, r;
> diff --git a/hw/vhost.h b/hw/vhost.h
> index 86dd834..c8c595a 100644
> --- a/hw/vhost.h
> +++ b/hw/vhost.h
> @@ -38,10 +38,12 @@ struct vhost_dev {
> bool log_enabled;
> vhost_log_chunk_t *log;
> unsigned long long log_size;
> + bool force;
> };
>
> -int vhost_dev_init(struct vhost_dev *hdev, int devfd);
> +int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force);
> void vhost_dev_cleanup(struct vhost_dev *hdev);
> +bool vhost_dev_query(struct vhost_dev *hdev, VirtIODevice *vdev);
> int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev);
> void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev);
>
> diff --git a/hw/vhost_net.c b/hw/vhost_net.c
> index c068be1..420e05f 100644
> --- a/hw/vhost_net.c
> +++ b/hw/vhost_net.c
> @@ -81,7 +81,8 @@ static int vhost_net_get_fd(VLANClientState *backend)
> }
> }
>
> -struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
> +struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd,
> + bool force)
> {
> int r;
> struct vhost_net *net = qemu_malloc(sizeof *net);
> @@ -98,7 +99,7 @@ struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
> (1 << VHOST_NET_F_VIRTIO_NET_HDR);
> net->backend = r;
>
> - r = vhost_dev_init(&net->dev, devfd);
> + r = vhost_dev_init(&net->dev, devfd, force);
> if (r < 0) {
> goto fail;
> }
> @@ -121,6 +122,11 @@ fail:
> return NULL;
> }
>
> +bool vhost_net_query(VHostNetState *net, VirtIODevice *dev)
> +{
> + return vhost_dev_query(&net->dev, dev);
> +}
> +
> int vhost_net_start(struct vhost_net *net,
> VirtIODevice *dev)
> {
> @@ -188,15 +194,21 @@ void vhost_net_cleanup(struct vhost_net *net)
> qemu_free(net);
> }
> #else
> -struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
> +struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd,
> + bool force)
> +{
> + return NULL;
> +}
> +
> +bool vhost_net_query(VHostNetState *net, VirtIODevice *dev)
> {
> - return NULL;
> + return false;
> }
>
> int vhost_net_start(struct vhost_net *net,
> VirtIODevice *dev)
> {
> - return -ENOSYS;
> + return -ENOSYS;
> }
> void vhost_net_stop(struct vhost_net *net,
> VirtIODevice *dev)
> @@ -209,7 +221,7 @@ void vhost_net_cleanup(struct vhost_net *net)
>
> unsigned vhost_net_get_features(struct vhost_net *net, unsigned features)
> {
> - return features;
> + return features;
> }
> void vhost_net_ack_features(struct vhost_net *net, unsigned features)
> {
> diff --git a/hw/vhost_net.h b/hw/vhost_net.h
> index 6c18ff7..91e40b1 100644
> --- a/hw/vhost_net.h
> +++ b/hw/vhost_net.h
> @@ -6,8 +6,9 @@
> struct vhost_net;
> typedef struct vhost_net VHostNetState;
>
> -VHostNetState *vhost_net_init(VLANClientState *backend, int devfd);
> +VHostNetState *vhost_net_init(VLANClientState *backend, int devfd, bool force);
>
> +bool vhost_net_query(VHostNetState *net, VirtIODevice *dev);
> int vhost_net_start(VHostNetState *net, VirtIODevice *dev);
> void vhost_net_stop(VHostNetState *net, VirtIODevice *dev);
>
> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> index ccb3e63..16ac103 100644
> --- a/hw/virtio-net.c
> +++ b/hw/virtio-net.c
> @@ -119,7 +119,11 @@ static void virtio_net_vhost_status(VirtIONet *n, uint8_t status)
> return;
> }
> if (!n->vhost_started) {
> - int r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
> + int r;
> + if (!vhost_net_query(tap_get_vhost_net(n->nic->nc.peer), &n->vdev)) {
> + return;
> + }
> + r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
> if (r < 0) {
> error_report("unable to start vhost net: %d: "
> "falling back on userspace virtio", -r);
> diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> index d07ff97..3911b09 100644
> --- a/hw/virtio-pci.c
> +++ b/hw/virtio-pci.c
> @@ -595,6 +595,12 @@ static int virtio_pci_set_guest_notifier(void *opaque, int n, bool assign)
> return 0;
> }
>
> +static bool virtio_pci_query_guest_notifiers(void *opaque)
> +{
> + VirtIOPCIProxy *proxy = opaque;
> + return msix_enabled(&proxy->pci_dev);
> +}
> +
> static int virtio_pci_set_guest_notifiers(void *opaque, bool assign)
> {
> VirtIOPCIProxy *proxy = opaque;
> @@ -658,6 +664,7 @@ static const VirtIOBindings virtio_pci_bindings = {
> .save_queue = virtio_pci_save_queue,
> .load_queue = virtio_pci_load_queue,
> .get_features = virtio_pci_get_features,
> + .query_guest_notifiers = virtio_pci_query_guest_notifiers,
> .set_host_notifier = virtio_pci_set_host_notifier,
> .set_guest_notifiers = virtio_pci_set_guest_notifiers,
> .vmstate_change = virtio_pci_vmstate_change,
> diff --git a/hw/virtio.h b/hw/virtio.h
> index d8546d5..31d16e1 100644
> --- a/hw/virtio.h
> +++ b/hw/virtio.h
> @@ -93,6 +93,7 @@ typedef struct {
> int (*load_config)(void * opaque, QEMUFile *f);
> int (*load_queue)(void * opaque, int n, QEMUFile *f);
> unsigned (*get_features)(void * opaque);
> + bool (*query_guest_notifiers)(void * opaque);
> int (*set_guest_notifiers)(void * opaque, bool assigned);
> int (*set_host_notifier)(void * opaque, int n, bool assigned);
> void (*vmstate_change)(void * opaque, bool running);
> diff --git a/net/tap.c b/net/tap.c
> index eada34a..b8cd252 100644
> --- a/net/tap.c
> +++ b/net/tap.c
> @@ -491,8 +491,10 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char *name, VLANState *vlan
> }
> }
>
> - if (qemu_opt_get_bool(opts, "vhost", !!qemu_opt_get(opts, "vhostfd"))) {
> + if (qemu_opt_get_bool(opts, "vhost", !!qemu_opt_get(opts, "vhostfd") ||
> + qemu_opt_get_bool(opts, "vhostforce", false))) {
> int vhostfd, r;
> + bool force = qemu_opt_get_bool(opts, "vhostforce", false);
> if (qemu_opt_get(opts, "vhostfd")) {
> r = net_handle_fd_param(mon, qemu_opt_get(opts, "vhostfd"));
> if (r == -1) {
> @@ -502,7 +504,7 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char *name, VLANState *vlan
> } else {
> vhostfd = -1;
> }
> - s->vhost_net = vhost_net_init(&s->nc, vhostfd);
> + s->vhost_net = vhost_net_init(&s->nc, vhostfd, force);
> if (!s->vhost_net) {
> error_report("vhost-net requested but could not be initialized");
> return -1;
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 898561d..11c93a2 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1050,7 +1050,7 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
> "-net tap[,vlan=n][,name=str],ifname=name\n"
> " connect the host TAP network interface to VLAN 'n'\n"
> #else
> - "-net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h]\n"
> + "-net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h][,vhostforce=on|off]\n"
> " connect the host TAP network interface to VLAN 'n' and use the\n"
> " network scripts 'file' (default=" DEFAULT_NETWORK_SCRIPT ")\n"
> " and 'dfile' (default=" DEFAULT_NETWORK_DOWN_SCRIPT ")\n"
> @@ -1061,6 +1061,8 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
> " use vnet_hdr=off to avoid enabling the IFF_VNET_HDR tap flag\n"
> " use vnet_hdr=on to make the lack of IFF_VNET_HDR support an error condition\n"
> " use vhost=on to enable experimental in kernel accelerator\n"
> + " (only has effect for virtio guests which use MSIX)\n"
> + " use vhostforce=on to force vhost on for non-MSIX virtio guests\n"
> " use 'vhostfd=h' to connect to an already opened vhost net device\n"
> #endif
> "-net socket[,vlan=n][,name=str][,fd=h][,listen=[host]:port][,connect=host:port]\n"
^ permalink raw reply
* [Qemu-devel] Re: [PATCHv3 0.14] vhost: force vhost off for non-MSI guests
From: Alex Williamson @ 2011-02-01 20:30 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, Quintela, Jes.Sorensen, jasowang, qemu-devel, Juan
In-Reply-To: <20110201201342.GA30006@redhat.com>
On Tue, 2011-02-01 at 22:13 +0200, Michael S. Tsirkin wrote:
> When MSI is off, each interrupt needs to be bounced through the io
> thread when it's set/cleared, so vhost-net causes more context switches and
> higher CPU utilization than userspace virtio which handles networking in
> the same thread.
>
> We'll need to fix this by adding level irq support in kvm irqfd,
> for now disable vhost-net in these configurations.
>
> Added a vhostforce flag to force vhost-net back on.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> OK this is 0.14 material so quick review would be appreciated.
> This version's compiled only, I'll naturally test more before I
> queue it.
>
> Changes from v2:
> get rid of EVIRTIO, add a separate API to query
> for fast guest notifiers
I like this better. Thanks,
Alex
> Changes from v1:
> add vhostforce flag
>
> hw/vhost.c | 10 +++++++++-
> hw/vhost.h | 4 +++-
> hw/vhost_net.c | 24 ++++++++++++++++++------
> hw/vhost_net.h | 3 ++-
> hw/virtio-net.c | 6 +++++-
> hw/virtio-pci.c | 7 +++++++
> hw/virtio.h | 1 +
> net/tap.c | 6 ++++--
> qemu-options.hx | 4 +++-
> 9 files changed, 52 insertions(+), 13 deletions(-)
>
> diff --git a/hw/vhost.c b/hw/vhost.c
> index 6082da2..38cc3b3 100644
> --- a/hw/vhost.c
> +++ b/hw/vhost.c
> @@ -581,7 +581,7 @@ static void vhost_virtqueue_cleanup(struct vhost_dev *dev,
> 0, virtio_queue_get_desc_size(vdev, idx));
> }
>
> -int vhost_dev_init(struct vhost_dev *hdev, int devfd)
> +int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force)
> {
> uint64_t features;
> int r;
> @@ -613,6 +613,7 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd)
> hdev->log_enabled = false;
> hdev->started = false;
> cpu_register_phys_memory_client(&hdev->client);
> + hdev->force = force;
> return 0;
> fail:
> r = -errno;
> @@ -627,6 +628,13 @@ void vhost_dev_cleanup(struct vhost_dev *hdev)
> close(hdev->control);
> }
>
> +bool vhost_dev_query(struct vhost_dev *hdev, VirtIODevice *vdev)
> +{
> + return !vdev->binding->query_guest_notifiers ||
> + vdev->binding->query_guest_notifiers(vdev->binding_opaque) ||
> + hdev->force;
> +}
> +
> int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev)
> {
> int i, r;
> diff --git a/hw/vhost.h b/hw/vhost.h
> index 86dd834..c8c595a 100644
> --- a/hw/vhost.h
> +++ b/hw/vhost.h
> @@ -38,10 +38,12 @@ struct vhost_dev {
> bool log_enabled;
> vhost_log_chunk_t *log;
> unsigned long long log_size;
> + bool force;
> };
>
> -int vhost_dev_init(struct vhost_dev *hdev, int devfd);
> +int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force);
> void vhost_dev_cleanup(struct vhost_dev *hdev);
> +bool vhost_dev_query(struct vhost_dev *hdev, VirtIODevice *vdev);
> int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev);
> void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev);
>
> diff --git a/hw/vhost_net.c b/hw/vhost_net.c
> index c068be1..420e05f 100644
> --- a/hw/vhost_net.c
> +++ b/hw/vhost_net.c
> @@ -81,7 +81,8 @@ static int vhost_net_get_fd(VLANClientState *backend)
> }
> }
>
> -struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
> +struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd,
> + bool force)
> {
> int r;
> struct vhost_net *net = qemu_malloc(sizeof *net);
> @@ -98,7 +99,7 @@ struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
> (1 << VHOST_NET_F_VIRTIO_NET_HDR);
> net->backend = r;
>
> - r = vhost_dev_init(&net->dev, devfd);
> + r = vhost_dev_init(&net->dev, devfd, force);
> if (r < 0) {
> goto fail;
> }
> @@ -121,6 +122,11 @@ fail:
> return NULL;
> }
>
> +bool vhost_net_query(VHostNetState *net, VirtIODevice *dev)
> +{
> + return vhost_dev_query(&net->dev, dev);
> +}
> +
> int vhost_net_start(struct vhost_net *net,
> VirtIODevice *dev)
> {
> @@ -188,15 +194,21 @@ void vhost_net_cleanup(struct vhost_net *net)
> qemu_free(net);
> }
> #else
> -struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
> +struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd,
> + bool force)
> +{
> + return NULL;
> +}
> +
> +bool vhost_net_query(VHostNetState *net, VirtIODevice *dev)
> {
> - return NULL;
> + return false;
> }
>
> int vhost_net_start(struct vhost_net *net,
> VirtIODevice *dev)
> {
> - return -ENOSYS;
> + return -ENOSYS;
> }
> void vhost_net_stop(struct vhost_net *net,
> VirtIODevice *dev)
> @@ -209,7 +221,7 @@ void vhost_net_cleanup(struct vhost_net *net)
>
> unsigned vhost_net_get_features(struct vhost_net *net, unsigned features)
> {
> - return features;
> + return features;
> }
> void vhost_net_ack_features(struct vhost_net *net, unsigned features)
> {
> diff --git a/hw/vhost_net.h b/hw/vhost_net.h
> index 6c18ff7..91e40b1 100644
> --- a/hw/vhost_net.h
> +++ b/hw/vhost_net.h
> @@ -6,8 +6,9 @@
> struct vhost_net;
> typedef struct vhost_net VHostNetState;
>
> -VHostNetState *vhost_net_init(VLANClientState *backend, int devfd);
> +VHostNetState *vhost_net_init(VLANClientState *backend, int devfd, bool force);
>
> +bool vhost_net_query(VHostNetState *net, VirtIODevice *dev);
> int vhost_net_start(VHostNetState *net, VirtIODevice *dev);
> void vhost_net_stop(VHostNetState *net, VirtIODevice *dev);
>
> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> index ccb3e63..16ac103 100644
> --- a/hw/virtio-net.c
> +++ b/hw/virtio-net.c
> @@ -119,7 +119,11 @@ static void virtio_net_vhost_status(VirtIONet *n, uint8_t status)
> return;
> }
> if (!n->vhost_started) {
> - int r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
> + int r;
> + if (!vhost_net_query(tap_get_vhost_net(n->nic->nc.peer), &n->vdev)) {
> + return;
> + }
> + r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
> if (r < 0) {
> error_report("unable to start vhost net: %d: "
> "falling back on userspace virtio", -r);
> diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> index d07ff97..3911b09 100644
> --- a/hw/virtio-pci.c
> +++ b/hw/virtio-pci.c
> @@ -595,6 +595,12 @@ static int virtio_pci_set_guest_notifier(void *opaque, int n, bool assign)
> return 0;
> }
>
> +static bool virtio_pci_query_guest_notifiers(void *opaque)
> +{
> + VirtIOPCIProxy *proxy = opaque;
> + return msix_enabled(&proxy->pci_dev);
> +}
> +
> static int virtio_pci_set_guest_notifiers(void *opaque, bool assign)
> {
> VirtIOPCIProxy *proxy = opaque;
> @@ -658,6 +664,7 @@ static const VirtIOBindings virtio_pci_bindings = {
> .save_queue = virtio_pci_save_queue,
> .load_queue = virtio_pci_load_queue,
> .get_features = virtio_pci_get_features,
> + .query_guest_notifiers = virtio_pci_query_guest_notifiers,
> .set_host_notifier = virtio_pci_set_host_notifier,
> .set_guest_notifiers = virtio_pci_set_guest_notifiers,
> .vmstate_change = virtio_pci_vmstate_change,
> diff --git a/hw/virtio.h b/hw/virtio.h
> index d8546d5..31d16e1 100644
> --- a/hw/virtio.h
> +++ b/hw/virtio.h
> @@ -93,6 +93,7 @@ typedef struct {
> int (*load_config)(void * opaque, QEMUFile *f);
> int (*load_queue)(void * opaque, int n, QEMUFile *f);
> unsigned (*get_features)(void * opaque);
> + bool (*query_guest_notifiers)(void * opaque);
> int (*set_guest_notifiers)(void * opaque, bool assigned);
> int (*set_host_notifier)(void * opaque, int n, bool assigned);
> void (*vmstate_change)(void * opaque, bool running);
> diff --git a/net/tap.c b/net/tap.c
> index eada34a..b8cd252 100644
> --- a/net/tap.c
> +++ b/net/tap.c
> @@ -491,8 +491,10 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char *name, VLANState *vlan
> }
> }
>
> - if (qemu_opt_get_bool(opts, "vhost", !!qemu_opt_get(opts, "vhostfd"))) {
> + if (qemu_opt_get_bool(opts, "vhost", !!qemu_opt_get(opts, "vhostfd") ||
> + qemu_opt_get_bool(opts, "vhostforce", false))) {
> int vhostfd, r;
> + bool force = qemu_opt_get_bool(opts, "vhostforce", false);
> if (qemu_opt_get(opts, "vhostfd")) {
> r = net_handle_fd_param(mon, qemu_opt_get(opts, "vhostfd"));
> if (r == -1) {
> @@ -502,7 +504,7 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char *name, VLANState *vlan
> } else {
> vhostfd = -1;
> }
> - s->vhost_net = vhost_net_init(&s->nc, vhostfd);
> + s->vhost_net = vhost_net_init(&s->nc, vhostfd, force);
> if (!s->vhost_net) {
> error_report("vhost-net requested but could not be initialized");
> return -1;
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 898561d..11c93a2 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1050,7 +1050,7 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
> "-net tap[,vlan=n][,name=str],ifname=name\n"
> " connect the host TAP network interface to VLAN 'n'\n"
> #else
> - "-net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h]\n"
> + "-net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h][,vhostforce=on|off]\n"
> " connect the host TAP network interface to VLAN 'n' and use the\n"
> " network scripts 'file' (default=" DEFAULT_NETWORK_SCRIPT ")\n"
> " and 'dfile' (default=" DEFAULT_NETWORK_DOWN_SCRIPT ")\n"
> @@ -1061,6 +1061,8 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
> " use vnet_hdr=off to avoid enabling the IFF_VNET_HDR tap flag\n"
> " use vnet_hdr=on to make the lack of IFF_VNET_HDR support an error condition\n"
> " use vhost=on to enable experimental in kernel accelerator\n"
> + " (only has effect for virtio guests which use MSIX)\n"
> + " use vhostforce=on to force vhost on for non-MSIX virtio guests\n"
> " use 'vhostfd=h' to connect to an already opened vhost net device\n"
> #endif
> "-net socket[,vlan=n][,name=str][,fd=h][,listen=[host]:port][,connect=host:port]\n"
^ permalink raw reply
* Re: Ralink RT2501/RT2573 USB Wireless Adapter crashes kernel 2.6.37
From: Eric Fernandez @ 2011-02-01 20:31 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: linux-wireless
In-Reply-To: <20110201114757.GA11930@sig21.net>
2011/2/1 Johannes Stezenbach <js@sig21.net>:
>
> If it still crashes, can you check dmesg for the crash messages?
>
>
> Thanks,
> Johannes
>
Hi,
this is what I get in /var/log/messages after I plug in the adapter:
Feb 1 20:22:39 localhost kernel: usb 2-2: new high speed USB device
using ehci_hcd and address 3
Feb 1 20:22:39 localhost kernel: cfg80211: Calling CRDA to update
world regulatory domain
Feb 1 20:22:39 localhost kernel: usbcore: registered new interface
driver rt2500usb
Feb 1 20:22:39 localhost kernel: PGD 154c063 PUD 1fffc067 PMD 80000000c94001e3
Feb 1 20:22:39 localhost kernel: CPU 1
Feb 1 20:22:39 localhost kernel: Modules linked in: rt73usb(+)
rt2500usb rt2x00usb rt2x00lib mac80211 cfg80211 rfkill ipv6 it87
adt7475 hwmon_vid ext3 jbd nls_cp437 vfat fat joydev usbhid hid
nvidia(P) uvcvideo videodev v4l1_compat v4l2_compat_ioctl32
snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device r8169 mii firewire_ohci
firewire_core crc_itu_t uhci_hcd ehci_hcd usbcore
snd_hda_codec_realtek shpchp pci_hotplug snd_hda_intel snd_hda_codec
snd_hwdep snd_pcm pcspkr snd_timer snd soundcore snd_page_alloc sg
evdev processor button i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support
serio_raw ext4 mbcache jbd2 crc16 sr_mod cdrom pata_jmicron pata_acpi
sd_mod ahci libahci libata scsi_mod
Feb 1 20:22:39 localhost kernel:
Feb 1 20:22:39 localhost kernel: Pid: 7507, comm: modprobe Tainted: P
2.6.37-ARCH #1 P55M-UD2/P55M-UD2
Feb 1 20:22:39 localhost kernel: RIP: 0010:[<ffff8800c94bcc28>]
[<ffff8800c94bcc28>] 0xffff8800c94bcc28
Feb 1 20:22:39 localhost kernel: RSP: 0018:ffff8800b6a19b20 EFLAGS: 00010286
Feb 1 20:22:39 localhost kernel: RAX: ffff8800c94bcc28 RBX:
ffff8800c1bd81a8 RCX: 0000000000000000
Feb 1 20:22:39 localhost kernel: RDX: 0000000000000000 RSI:
ffff8800c1bd81a8 RDI: ffff8800c1bd81a8
Feb 1 20:22:39 localhost kernel: RBP: ffff8800b6a19b38 R08:
0000000000000001 R09: 0000000000000000
Feb 1 20:22:39 localhost kernel: R10: 0000000000000000 R11:
0000000000000000 R12: ffff8800c94b9c30
Feb 1 20:22:39 localhost kernel: R13: ffff8800bbaf0240 R14:
ffff8800c979e2c8 R15: 0000000000000000
Feb 1 20:22:39 localhost kernel: FS: 00007f2e5b3c7700(0000)
GS:ffff8800df440000(0000) knlGS:0000000000000000
Feb 1 20:22:39 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
Feb 1 20:22:39 localhost kernel: CR2: ffff8800c94bcc28 CR3:
00000000b6be9000 CR4: 00000000000006e0
Feb 1 20:22:39 localhost kernel: DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Feb 1 20:22:39 localhost kernel: DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Feb 1 20:22:39 localhost kernel: Process modprobe (pid: 7507,
threadinfo ffff8800b6a18000, task ffff880117cc29a0)
Feb 1 20:22:39 localhost kernel: ffffffff8138de74 ffff8800c94b9c30
ffff8800c1bd81a8 ffff8800b6a19b58
Feb 1 20:22:39 localhost kernel: ffffffff8138dfa2 ffff8800c979e080
ffff8800c979e090 ffff8800b6a19bd8
Feb 1 20:22:39 localhost kernel: ffffffff812ae58a ffff880000000007
0000000000000000 ffffffffa0085ea0
Feb 1 20:22:39 localhost kernel: [<ffffffff8138de74>] ?
klist_node_init+0x44/0x70
Feb 1 20:22:39 localhost kernel: [<ffffffff8138dfa2>] klist_add_tail+0x22/0x60
Feb 1 20:22:39 localhost kernel: [<ffffffff812ae58a>] device_add+0x4fa/0x5c0
Feb 1 20:22:39 localhost kernel: [<ffffffffa00846af>]
rfkill_register+0x9f/0x270 [rfkill]
Feb 1 20:22:39 localhost kernel: [<ffffffffa0cdf096>]
wiphy_register+0x246/0x340 [cfg80211]
Feb 1 20:22:39 localhost kernel: [<ffffffff81127e2b>] ? __kmalloc+0x19b/0x280
Feb 1 20:22:39 localhost kernel: [<ffffffffa0d032e7>]
ieee80211_register_hw+0x167/0x520 [mac80211]
Feb 1 20:22:39 localhost kernel: [<ffffffffa0d43e40>]
rt2x00lib_probe_dev+0x2e0/0x4c0 [rt2x00lib]
Feb 1 20:22:39 localhost kernel: [<ffffffffa01502ad>]
rt2x00usb_probe+0x14d/0x310 [rt2x00usb]
Feb 1 20:22:39 localhost kernel: [<ffffffffa02ce359>]
usb_probe_interface+0x109/0x200 [usbcore]
Feb 1 20:22:39 localhost kernel: [<ffffffff812b11e6>]
driver_probe_device+0x96/0x1c0
Feb 1 20:22:39 localhost kernel: [<ffffffff812b13ab>] __driver_attach+0x9b/0xa0
Feb 1 20:22:39 localhost kernel: [<ffffffff812b1310>] ?
__driver_attach+0x0/0xa0
Feb 1 20:22:39 localhost kernel: [<ffffffff812b012e>]
bus_for_each_dev+0x5e/0x90
Feb 1 20:22:39 localhost kernel: [<ffffffff812b0e89>] driver_attach+0x19/0x20
Feb 1 20:22:39 localhost kernel: [<ffffffff812b0a18>]
bus_add_driver+0x158/0x300
Feb 1 20:22:39 localhost kernel: [<ffffffff812b1621>]
driver_register+0x71/0x140
Feb 1 20:22:39 localhost kernel: [<ffffffff8107d50d>] ?
notifier_call_chain+0x4d/0x70
Feb 1 20:22:39 localhost kernel: [<ffffffffa02cd078>]
usb_register_driver+0xb8/0x170 [usbcore]
Feb 1 20:22:39 localhost kernel: [<ffffffffa01c8000>] ?
rt73usb_init+0x0/0x20 [rt73usb]
Feb 1 20:22:39 localhost kernel: [<ffffffffa01c801e>]
rt73usb_init+0x1e/0x20 [rt73usb]
Feb 1 20:22:39 localhost kernel: [<ffffffff8100212f>]
do_one_initcall+0x3f/0x180
Feb 1 20:22:39 localhost kernel: [<ffffffff81093ebb>]
sys_init_module+0xbb/0x200
Feb 1 20:22:39 localhost kernel: [<ffffffff8100bf12>]
system_call_fastpath+0x16/0x1b
Feb 1 20:22:39 localhost kernel: RSP <ffff8800b6a19b20>
Feb 1 20:22:39 localhost kernel: ---[ end trace 0d76df522e93fe83 ]---
Feb 1 20:23:10 localhost kernel: usb 2-2: USB disconnect, address 3
Feb 1 20:23:22 localhost kernel: CE: hpet6 increased min_delta_ns to 7500 nsec
Feb 1 20:23:22 localhost kernel: CE: hpet6 increased min_delta_ns to 11250 nsec
Hope this helps.
Eric
^ permalink raw reply
* Re: What's the typical RAID10 setup?
From: Keld Jørn Simonsen @ 2011-02-01 20:32 UTC (permalink / raw)
To: Keld Jørn Simonsen; +Cc: David Brown, linux-raid
In-Reply-To: <20110201160245.GA25659@www2.open-std.org>
On Tue, Feb 01, 2011 at 05:02:46PM +0100, Keld Jørn Simonsen wrote:
> On Tue, Feb 01, 2011 at 11:01:33AM +0100, David Brown wrote:
> > On 31/01/2011 23:52, Keld Jørn Simonsen wrote:
> > >raid1+0 and Linux MD raid10 are similar, but significantly different
> > >in a number of ways. Linux MD raid10 can run on only 2 drives.
> > >Linux raid10,f2 has almost RAID0 striping performance in sequential read.
> > >You can have an odd number of drives in raid10.
> > >And you can have as many copies as you like in raid10,
> > >
> >
> > You can make raid10,f2 functionality from raid1+0 by using partitions.
> > For example, to get a raid10,f2 equivalent on two drives, partition them
> > into equal halves. Then make md0 a raid1 mirror of sda1 and sdb2, and
> > md1 a raid1 mirror of sdb1 and sda2. Finally, make md2 a raid0 stripe
> > set of md0 and md1.
>
> I don't think you get the striping performance of raid10,f2 with this
> layout. And that is one of the main advantages of raid10,f2 layout.
> Have you tried it out?
>
> As far as I can see the layout of blocks are not alternating between the
> disks. You have one raid1 of sda1 and sdb2, there a file is allocated on
> blocks sequentially on sda1 and then mirrored on sdb2, where it is also
> sequentially allocated. That gives no striping.
Well, maybe the RAID0 layer provides the adequate striping.
I am noy sure, but it looks like it could hold in theory.
One could try it out.
One advantage of this scheme could be improved probability
When 2 drives fail, eg. in the case of a 4 drive array.
The probability of survival of a running system could then
be enhaced form 33 % to 66 %.
One problem could be the choice of always the lowest block number, which
is secured in raid10,f2, but not in a raid0 over raid1 (or raid10,n2) scenario.
best regards
keld
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch 01/28] time: Correct the *settime* parameters
From: john stultz @ 2011-02-01 20:32 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110201134417.545698637@linutronix.de>
On Tue, 2011-02-01 at 13:50 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (time-correct-the-settime-parameters.patch)
> Both settimeofday() and clock_settime() promise with a 'const'
> attribute not to alter the arguments passed in. This patch adds the
> missing 'const' attribute into the various kernel functions
> implementing these calls.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> Cc: John Stultz <john.stultz@linaro.org>
> LKML-Reference: <681d9f8ba43fea01bae9f6a17a4674194a90353b.1296124770.git.richard.cochran@omicron.at>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: John Stultz <johnstul@us.ibm.com>
^ permalink raw reply
* Re: [patch 02/28] posix-timers: Define nanosleep not supported error separate
From: John Stultz @ 2011-02-01 20:32 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110201134417.643486574@linutronix.de>
On Tue, 2011-02-01 at 13:51 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (posix-clocks-splitout-nanosleep-notsup-error.patch)
> Define the conditional nanosleep not supported error value outside of
> do_posix_clock_nonanosleep(). Preparatory patch for further cleanups.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: John Stultz <john.stultz@linaro.org>
> Cc: Richard Cochran <richard.cochran@omicron.at>
Acked-by: John Stultz <johnstul@us.ibm.com>
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Saravana Kannan @ 2011-02-01 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201152458.GP31216@n2100.arm.linux.org.uk>
On 02/01/2011 07:24 AM, Russell King - ARM Linux wrote:
> A simpler way to write this is:
>
> int clk_prepare(struct clk *clk)
> {
> int ret = 0;
>
> mutex_lock(&clk->mutex);
> if (clk->prepared = 0)
> ret = clk->ops->prepare(clk);
> if (ret = 0)
> clk->prepared++;
> mutex_unlock(&clk->mutex);
>
> return ret;
> }
>
> I think we want to take a common mutex not only for clk_prepare(), but
> also for clk_set_rate(). If prepare() is waiting for a PLL to lock,
> we don't want a set_rate() interfering with that.
Looks like this is the best acknowledgment/response I can expect to get
from Russell on this point that I raised.
Jeremy,
When you update the comments/doc to indicate clk_prepare/unprepare is
not atomic, can you also update the comment for set_rate() and mark it
as non-atomic?
Thanks for starting this thread. My efforts to reignite the other thread
didn't go anywhere. Glad to see it's moving forward.
> I'd also be tempted at this stage to build-in a no-op dummy clock,
> that being the NULL clk:
>[snip]
> as we have various platforms defining a dummy struct clk as a way of
> satisfying various driver requirements. These dummy clocks are exactly
> that - they're complete no-ops.
Unrelated to this thread, but I Ack this request too.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Saravana Kannan @ 2011-02-01 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201152458.GP31216@n2100.arm.linux.org.uk>
On 02/01/2011 07:24 AM, Russell King - ARM Linux wrote:
> A simpler way to write this is:
>
> int clk_prepare(struct clk *clk)
> {
> int ret = 0;
>
> mutex_lock(&clk->mutex);
> if (clk->prepared == 0)
> ret = clk->ops->prepare(clk);
> if (ret == 0)
> clk->prepared++;
> mutex_unlock(&clk->mutex);
>
> return ret;
> }
>
> I think we want to take a common mutex not only for clk_prepare(), but
> also for clk_set_rate(). If prepare() is waiting for a PLL to lock,
> we don't want a set_rate() interfering with that.
Looks like this is the best acknowledgment/response I can expect to get
from Russell on this point that I raised.
Jeremy,
When you update the comments/doc to indicate clk_prepare/unprepare is
not atomic, can you also update the comment for set_rate() and mark it
as non-atomic?
Thanks for starting this thread. My efforts to reignite the other thread
didn't go anywhere. Glad to see it's moving forward.
> I'd also be tempted at this stage to build-in a no-op dummy clock,
> that being the NULL clk:
>[snip]
> as we have various platforms defining a dummy struct clk as a way of
> satisfying various driver requirements. These dummy clocks are exactly
> that - they're complete no-ops.
Unrelated to this thread, but I Ack this request too.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Saravana Kannan @ 2011-02-01 20:33 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Uwe Kleine-König, Nicolas Pitre, Lorenzo Pieralisi, linux-sh,
Ben Herrenschmidt, Sascha Hauer, Paul Mundt, linux-kernel,
Dima Zavin, Ben Dooks, Vincent Guittot, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <20110201152458.GP31216@n2100.arm.linux.org.uk>
On 02/01/2011 07:24 AM, Russell King - ARM Linux wrote:
> A simpler way to write this is:
>
> int clk_prepare(struct clk *clk)
> {
> int ret = 0;
>
> mutex_lock(&clk->mutex);
> if (clk->prepared == 0)
> ret = clk->ops->prepare(clk);
> if (ret == 0)
> clk->prepared++;
> mutex_unlock(&clk->mutex);
>
> return ret;
> }
>
> I think we want to take a common mutex not only for clk_prepare(), but
> also for clk_set_rate(). If prepare() is waiting for a PLL to lock,
> we don't want a set_rate() interfering with that.
Looks like this is the best acknowledgment/response I can expect to get
from Russell on this point that I raised.
Jeremy,
When you update the comments/doc to indicate clk_prepare/unprepare is
not atomic, can you also update the comment for set_rate() and mark it
as non-atomic?
Thanks for starting this thread. My efforts to reignite the other thread
didn't go anywhere. Glad to see it's moving forward.
> I'd also be tempted at this stage to build-in a no-op dummy clock,
> that being the NULL clk:
>[snip]
> as we have various platforms defining a dummy struct clk as a way of
> satisfying various driver requirements. These dummy clocks are exactly
> that - they're complete no-ops.
Unrelated to this thread, but I Ack this request too.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [patch 03/28] posix-timers: Cleanup struct initializers
From: john stultz @ 2011-02-01 20:33 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110201134417.745627057@linutronix.de>
On Tue, 2011-02-01 at 13:51 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (posix-timers-cleanup-struct-initializers-codingstyle.patch)
> Cosmetic. No functional change
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: John Stultz <john.stultz@linaro.org>
> Cc: Richard Cochran <richard.cochran@omicron.at>
Acked-by: John Stultz <johnstul@us.ibm.com>
> ---
> drivers/char/mmtimer.c | 14 +++++++-------
> kernel/posix-cpu-timers.c | 24 ++++++++++++------------
> kernel/posix-timers.c | 38 +++++++++++++++++++-------------------
> 3 files changed, 38 insertions(+), 38 deletions(-)
>
> Index: linux-2.6-tip/drivers/char/mmtimer.c
> ===================================================================
> --- linux-2.6-tip.orig/drivers/char/mmtimer.c
> +++ linux-2.6-tip/drivers/char/mmtimer.c
> @@ -765,13 +765,13 @@ static int sgi_timer_set(struct k_itimer
>
> static struct k_clock sgi_clock = {
> .res = 0,
> - .clock_set = sgi_clock_set,
> - .clock_get = sgi_clock_get,
> - .timer_create = sgi_timer_create,
> - .nsleep = do_posix_clock_nonanosleep,
> - .timer_set = sgi_timer_set,
> - .timer_del = sgi_timer_del,
> - .timer_get = sgi_timer_get
> + .clock_set = sgi_clock_set,
> + .clock_get = sgi_clock_get,
> + .timer_create = sgi_timer_create,
> + .nsleep = do_posix_clock_nonanosleep,
> + .timer_set = sgi_timer_set,
> + .timer_del = sgi_timer_del,
> + .timer_get = sgi_timer_get
> };
>
> /**
> Index: linux-2.6-tip/kernel/posix-cpu-timers.c
> ===================================================================
> --- linux-2.6-tip.orig/kernel/posix-cpu-timers.c
> +++ linux-2.6-tip/kernel/posix-cpu-timers.c
> @@ -1607,20 +1607,20 @@ static long thread_cpu_nsleep_restart(st
> static __init int init_posix_cpu_timers(void)
> {
> struct k_clock process = {
> - .clock_getres = process_cpu_clock_getres,
> - .clock_get = process_cpu_clock_get,
> - .clock_set = do_posix_clock_nosettime,
> - .timer_create = process_cpu_timer_create,
> - .nsleep = process_cpu_nsleep,
> - .nsleep_restart = process_cpu_nsleep_restart,
> + .clock_getres = process_cpu_clock_getres,
> + .clock_get = process_cpu_clock_get,
> + .clock_set = do_posix_clock_nosettime,
> + .timer_create = process_cpu_timer_create,
> + .nsleep = process_cpu_nsleep,
> + .nsleep_restart = process_cpu_nsleep_restart,
> };
> struct k_clock thread = {
> - .clock_getres = thread_cpu_clock_getres,
> - .clock_get = thread_cpu_clock_get,
> - .clock_set = do_posix_clock_nosettime,
> - .timer_create = thread_cpu_timer_create,
> - .nsleep = thread_cpu_nsleep,
> - .nsleep_restart = thread_cpu_nsleep_restart,
> + .clock_getres = thread_cpu_clock_getres,
> + .clock_get = thread_cpu_clock_get,
> + .clock_set = do_posix_clock_nosettime,
> + .timer_create = thread_cpu_timer_create,
> + .nsleep = thread_cpu_nsleep,
> + .nsleep_restart = thread_cpu_nsleep_restart,
> };
> struct timespec ts;
>
> Index: linux-2.6-tip/kernel/posix-timers.c
> ===================================================================
> --- linux-2.6-tip.orig/kernel/posix-timers.c
> +++ linux-2.6-tip/kernel/posix-timers.c
> @@ -281,33 +281,33 @@ static int posix_get_coarse_res(const cl
> static __init int init_posix_timers(void)
> {
> struct k_clock clock_realtime = {
> - .clock_getres = hrtimer_get_res,
> + .clock_getres = hrtimer_get_res,
> };
> struct k_clock clock_monotonic = {
> - .clock_getres = hrtimer_get_res,
> - .clock_get = posix_ktime_get_ts,
> - .clock_set = do_posix_clock_nosettime,
> + .clock_getres = hrtimer_get_res,
> + .clock_get = posix_ktime_get_ts,
> + .clock_set = do_posix_clock_nosettime,
> };
> struct k_clock clock_monotonic_raw = {
> - .clock_getres = hrtimer_get_res,
> - .clock_get = posix_get_monotonic_raw,
> - .clock_set = do_posix_clock_nosettime,
> - .timer_create = no_timer_create,
> - .nsleep = no_nsleep,
> + .clock_getres = hrtimer_get_res,
> + .clock_get = posix_get_monotonic_raw,
> + .clock_set = do_posix_clock_nosettime,
> + .timer_create = no_timer_create,
> + .nsleep = no_nsleep,
> };
> struct k_clock clock_realtime_coarse = {
> - .clock_getres = posix_get_coarse_res,
> - .clock_get = posix_get_realtime_coarse,
> - .clock_set = do_posix_clock_nosettime,
> - .timer_create = no_timer_create,
> - .nsleep = no_nsleep,
> + .clock_getres = posix_get_coarse_res,
> + .clock_get = posix_get_realtime_coarse,
> + .clock_set = do_posix_clock_nosettime,
> + .timer_create = no_timer_create,
> + .nsleep = no_nsleep,
> };
> struct k_clock clock_monotonic_coarse = {
> - .clock_getres = posix_get_coarse_res,
> - .clock_get = posix_get_monotonic_coarse,
> - .clock_set = do_posix_clock_nosettime,
> - .timer_create = no_timer_create,
> - .nsleep = no_nsleep,
> + .clock_getres = posix_get_coarse_res,
> + .clock_get = posix_get_monotonic_coarse,
> + .clock_set = do_posix_clock_nosettime,
> + .timer_create = no_timer_create,
> + .nsleep = no_nsleep,
> };
>
> register_posix_clock(CLOCK_REALTIME, &clock_realtime);
>
>
^ permalink raw reply
* Early crash (was: Re: module: show version information for built-in modules in sysfs)
From: Geert Uytterhoeven @ 2011-02-01 20:33 UTC (permalink / raw)
To: Dmitry Torokhov, Rusty Russell; +Cc: linux-kernel, Linux/m68k
On Mon, Jan 24, 2011 at 11:59, Linux Kernel Mailing List
<linux-kernel@vger.kernel.org> wrote:
> Gitweb: http://git.kernel.org/linus/e94965ed5beb23c6fabf7ed31f625e66d7ff28de
> module: show version information for built-in modules in sysfs
>
> Currently only drivers that are built as modules have their versions
> shown in /sys/module/<module_name>/version, but this information might
> also be useful for built-in drivers as well. This especially important
> for drivers that do not define any parameters - such drivers, if
> built-in, are completely invisible from userspace.
>
> This patch changes MODULE_VERSION() macro so that in case when we are
> compiling built-in module, version information is stored in a separate
> section. Kernel then uses this data to create 'version' sysfs attribute
> in the same fashion it creates attributes for module parameters.
This commit causes the crash below on m68k (ARAnyM).
Reverting this commit and its dependency
3b90a5b292321b2acac3921f77046ae195aef53f
("module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=n")
makes it boot again.
NET: Registered protocol family 16
Unable to handle kernel NULL pointer dereference at virtual address 0000002b
Oops: 00000000
Modules linked in:
PC: [<00141164>] kset_find_obj_hinted+0x5a/0xb6
SR: 2300 SP: 00c09ec8 a2: 00c07900
d0: 00000078 d1: 00c2ee90 d2: 00000000 d3: 00000000
d4: 00000000 d5: 00000000 a0: 00c2f700 a1: 00c2f701
Process swapper (pid: 1, task=00c07900)
Frame format=7 eff addr=0000002b ssw=0525 faddr=0000002b
wb 1 stat/addr/data: 0000 00000000 00000000
wb 2 stat/addr/data: 0000 00000000 00000000
wb 3 stat/addr/data: 0000 0000002b 00000000
push data: 00000000 00000000 00000000 00000000
Stack from 00c09f30:
0000002b 002d853a 00310dac 0031214a 002dbff8 001411d0 00c2ee90 0000002b
00000000 00310dc2 00c2ee90 0000002b 00c2ee50 00000000 002d853a 00310eb8
0000002b 00000000 00000000 003291a8 00310e6c 00c1d8b8 002e6872 00170e00
00c1d8b0 002e6872 003031f8 00000000 00000000 00303038 0031bec2 0031214a
0031bf40 00303038 00000000 003291a4 000020f8 00000000 00000000 00000000
00000000 00000000 00000000 003291a8 00002008 0031214a 0030baee 00310e6c
Call Trace: [<00310dac>] locate_module_kobject+0x0/0xc0
[<0031214a>] __alloc_bootmem+0x0/0x1a
[<001411d0>] kset_find_obj+0x10/0x18
[<00310dc2>] locate_module_kobject+0x16/0xc0
[<00310eb8>] param_sysfs_init+0x4c/0x1be
[<00310e6c>] param_sysfs_init+0x0/0x1be
[<00170e00>] vtconsole_init_device+0x3c/0x90
[<0031bec2>] vtconsole_class_init+0x0/0xda
[<0031214a>] __alloc_bootmem+0x0/0x1a
[<0031bf40>] vtconsole_class_init+0x7e/0xda
[<000020f8>] do_one_initcall+0xf0/0x186
[<00002008>] do_one_initcall+0x0/0x186
[<0031214a>] __alloc_bootmem+0x0/0x1a
[<0030baee>] kernel_init+0x96/0x136
[<00310e6c>] param_sysfs_init+0x0/0x1be
[<0030ba58>] kernel_init+0x0/0x136
[<0002794e>] printk+0x0/0x1a
[<00002b52>] kernel_thread+0x3a/0x4e
Code: b288 672c 2053 4a88 6716 2248 2c4c 1019 <b01e> 6606 4a00 66f6
6002 9026 4a00 6722 47ed fffc 2a6b 0004 41eb 0004 b288 66d4
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill init!
Call Trace: [<0002745c>] panic+0x5a/0x1ba
[<00028bd4>] exit_mm+0x0/0x102
[<0011dfd6>] exit_sem+0x0/0x162
[<0002f5f2>] exit_ptrace+0x0/0x106
[<0002a274>] do_exit+0x6cc/0x6ce
[<0002794e>] printk+0x0/0x1a
[<000031de>] die_if_kernel+0x4e/0x52
[<00006e8c>] send_fault_sig+0xd4/0x11e
[<00006f80>] do_page_fault+0xaa/0x1c2
[<000038b6>] buserr_c+0x192/0x6d8
[<00100100>] mnt_xdr_dec_mountres+0xa2/0xb4
[<00002542>] buserr+0x1e/0x24
[<00310dac>] locate_module_kobject+0x0/0xc0
[<0031214a>] __alloc_bootmem+0x0/0x1a
[<001411d0>] kset_find_obj+0x10/0x18
[<00310dc2>] locate_module_kobject+0x16/0xc0
[<00310eb8>] param_sysfs_init+0x4c/0x1be
[<00310e6c>] param_sysfs_init+0x0/0x1be
[<00170e00>] vtconsole_init_device+0x3c/0x90
[<0031bec2>] vtconsole_class_init+0x0/0xda
[<0031214a>] __alloc_bootmem+0x0/0x1a
[<0031bf40>] vtconsole_class_init+0x7e/0xda
[<000020f8>] do_one_initcall+0xf0/0x186
[<00002008>] do_one_initcall+0x0/0x186
[<0031214a>] __alloc_bootmem+0x0/0x1a
[<0030baee>] kernel_init+0x96/0x136
[<00310e6c>] param_sysfs_init+0x0/0x1be
[<0030ba58>] kernel_init+0x0/0x136
[<0002794e>] printk+0x0/0x1a
[<00002b52>] kernel_thread+0x3a/0x4e
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.