* Re: [PATCH -rt] revert bh_lru_lock() to preempt_disable()
From: Daniel Walker @ 2006-05-03 21:01 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel
In-Reply-To: <20060503210125.GB16696@elte.hu>
On Wed, 2006-05-03 at 23:01 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> wrote:
>
> > > i agree that this is a problem, but the fix is incorrect. What would be
> > > the right approach is to convert the PER_CPU bh_lrus to PER_CPU_LOCKED,
> > > and to use the appropriate primitives to use them. That automatically
> > > makes this code rt-safe. (it isnt right now)
> >
> > Hmm, in UP it should be safe to access per cpu data under either a
> > preempt_disable or local_irq_disable . I'm not sure how RT changes
> > that .. Is there some other part of the code that isn't rt-safe, which
> > I've overlooked ?
>
> hm, you are right - that code can be in a preempt-off section. I've
> applied your patch.
We could switch it to locked types if it's a latency concern..
Daniel
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Junio C Hamano @ 2006-05-03 21:01 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7xibzbj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I agree with this 100%. I happened to be talking with Eric
> about the clone breakage he was having on #git channel, and I
Sorry, my memory is failing. It was Oejet I was talking with.
^ permalink raw reply
* Re: Linux 2.6.16.13 / Problem
From: Stephan von Krawczynski @ 2006-05-03 21:04 UTC (permalink / raw)
To: Bill Davidsen; +Cc: linux-kernel, stable, torvalds, ja
In-Reply-To: <44590B62.6000107@tmr.com>
On Wed, 03 May 2006 15:58:26 -0400
Bill Davidsen <davidsen@tmr.com> wrote:
> Stephan von Krawczynski wrote:
> > Hi Greg,
> >
> > unfortunately I see some problem regarding 2.6.16.13:
> >
> Did you see this behavior in 2.6.16.11 or .12? In other words is this a
> new problem, or one which just crawled out into view?
The box ran .11 since it existed without any troubles. The problems showed up
shortly after upgrading it to .13
I downgraded back to .11 now and everything is back to normal.
--
Regards,
Stephan
^ permalink raw reply
* [Bluez-devel] Power Class
From: Artur Almeida @ 2006-05-03 21:07 UTC (permalink / raw)
To: bluez-devel
[-- Attachment #1: Type: text/plain, Size: 263 bytes --]
Hi
Is there a way to find the power class (1.2..3) of the device? The pratical
example is im trying to bind a discovery service to a class2 device while
the obex service will run in a class1, both usb dongles in my desktop.
Thank you
Regards
Artur
[-- Attachment #2: Type: text/html, Size: 284 bytes --]
^ permalink raw reply
* Call for Presentations: Kernel Summit Dissenters Session
From: James Bottomley @ 2006-05-03 21:07 UTC (permalink / raw)
To: linux-kernel, ksummit-2006-pc
Do you think there is an area where the kernel developers are making a
fundamental mistake? Is there a better path we should be taking? If
you have a better idea - and are willing to argue your point in front of
several dozen assembled kernel hackers - please consider writing a
proposal for the 2006 Kernel Summit Dissenter's Session.
The program committee will review submitted proposals, looking for those
which seem most likely to result in an interesting and useful
discussion. A selected proposal will entitle the author to a seat at
the Summit (with the possibility of travel assistance if needed), and a
20-minute slot during the Dissenter's Session. A five-minute
presentation will be given, followed by fifteen minutes of discussion.
Ottawa has plenty of purveyors of good beer for recovery afterward.
If you are interested in presenting at the summit, please put together a
proposal of no more than 400 words and send it to the discussion list:
ksummit-2006-discuss@thunk.org
Proposals should describe the problem, how things should have been done
differently, and what can be done to fix it now. Winning proposals will
avoid topics which have been discussed into the ground (no devfs or C++,
please), and will cover a topic of interest to a large subset of the
development community. Proposals should be submitted by 20 May 2006.
^ permalink raw reply
* Re: [stable] Re: Linux 2.6.16.13 / Problem
From: Stephan von Krawczynski @ 2006-05-03 21:09 UTC (permalink / raw)
To: Greg KH; +Cc: gregkh, ja, torvalds, linux-kernel, stable
In-Reply-To: <20060503185409.GB10466@kroah.com>
On Wed, 3 May 2006 11:54:09 -0700
Greg KH <greg@kroah.com> wrote:
> On Wed, May 03, 2006 at 03:45:32PM +0200, Stephan von Krawczynski wrote:
> > Hi Greg,
> >
> > unfortunately I see some problem regarding 2.6.16.13:
>
> Makes sense, as nothing in .13 was for something like this :)
Sorry, didn't get that joke (no native englishman), you may explain in private
to me having spare time. Do you mean this is a _new_ story completely
unrelated to .13?
> Is this fixed in the 2.6.17-rc3 release?
I will check out tomorrow if rc3 makes any difference and keep you informed.
--
Regards,
Stephan
^ permalink raw reply
* Re: Problem using GIT CVS-server
From: Martin Langhoff @ 2006-05-03 21:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Panagiotis Issaris
In-Reply-To: <7v1wvaevno.fsf@assigned-by-dhcp.cox.net>
On 5/4/06, Junio C Hamano <junkio@cox.net> wrote:
> Ah, the "master" git-log is C-rewrite version and does not show
> the parents on the "commit (.*)" line itself with --parents.
Exactly.
> Could you see if the attached patch helps?
Will try it in a moment. Having thought about it, git-log is always
going to be tweaked for human consumption, so I should use something
geared for porcelains instead. git-rev-list does honour --parent, so
perhaps I should switch to using that instead?
cheers,
martin
^ permalink raw reply
* Re: We are attempting once again to split policy out into individual RPMS.
From: Joshua Brindle @ 2006-05-03 21:14 UTC (permalink / raw)
To: Karl MacMillan
Cc: Jeremy Katz, Daniel J Walsh, Stephen Smalley, SE Linux,
Paul Nasrat, James Antill
In-Reply-To: <1146683243.2766.42.camel@localhost.localdomain>
Karl MacMillan wrote:
> On Wed, 2006-05-03 at 15:02 -0400, Joshua Brindle wrote:
>
>> Karl MacMillan wrote:
>>
>>>>> The comparison to uid/gid is bogus, uid/gid are unambiguous, file
>>>>> contexts are ordered by specificity because multiple regexes can match
>>>>> any given filename. The file_contexts *must* be combined and ordered
>>>>> prior to labeling, and if multiple policy packages are being installed
>>>>> within a set those must all be included as well. matchpathcon does not
>>>>> currently have the sorting mechanism that libsemanage does to properly
>>>>> combine policy package file contexts.
>>>>>
>>>>>
>>>> By moving the policy to being maintained by the package maintainer, it's
>>>> moving towards having the file context be unambiguous as well.
>>>> Otherwise, the packager really has no control.
>>>>
>>>>
>>>>
>>> Both of these seem like positive changes, particularly having the
>>> package maintainers take responsibility for the SELinux policy
>>> associated with their package.
>>>
>>> Also, how ambiguous are the application file contexts now anyway? Josh,
>>> you are claiming that the labeling requires all of the file contexts to
>>> be combined, but for most applications that come with policy the file
>>> contexts are already a) specific and b) cover the majority of the files
>>> provided by that application. The more general file contexts are most
>>> useful for applications without policy.
>>>
>>>
>> Having unambiguous contexts for every package would not be scalable.
>> Most apps have some sort of fallback now (eg., mysql installs libraries
>> but doesn't label them, and shouldn't, the base library labeling should
>> take care of them). I imagine there are very few packages that have
>> entirely self contained file contexts files. Anything that installs
>> libraries, man pages, info pages, binaries without unique labels
>> (mysqladmin doesn't need its own label, only the daemon binary), etc.
>>
>> Not only does adding specific entries for every file in every package
>> not scale but it breaks encapsulation (why should a policy need to know
>> that /bin is bin_t, we intentionally abstracted that away in policy, why
>> regress in file contexts).
>>
>>
>
> Sure, but the common case is that the application specific file contexts
> can be combined with only the base policy file contexts to create the
> full labeling policy for that application.
>
This doesn't work every time though. For example, if you are installing
sendmail and thus installing the mta and sendmail policies the sendmail
binary _will not_ get labeled correctly just by looking at the sendmail
policy and the base policy. The sendmail binary is labeled via mta.fc. I
expect mutually dependent modules like this to increase over time, not
go away.
I still haven't heard why it is a problem to explicitly combine policy
packages within the same rpm transaction (since you are trying to
minimize transaction size) and do a rebuild/commit after that (and
before installing the apps). This seems pretty clear to me to be the
best solution but noone seems to be considering it at all.
And noone has addressed the fact that libselinux does not sort the
file_contexts the same way that libsemanage does when it writes it. This
leads to matchpathcon(foo.pp) producing different results than would be
produced if foo.pp were installed and matchpathcon() run.
I am baffled why the advocates of this believe making kernel tolerant of
inconsistent filesystem labels and allowing strange policy interactions
for the sake of bandaiding an inadequacy in RPM is better.. .*shrug*
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* RE: xm mem-set causes kernel panic
From: Ian Pratt @ 2006-05-03 21:15 UTC (permalink / raw)
To: Krysan, Susan, xen-devel
Cc: Subrahmanian, Raj, Vessey, Bruce A, Puthiyaparambil, Aravindh,
Carb, Brian A
> We did run using unstable. We installed sles10 beta11 but we
> pulled and built xen-unstable changeset 9903 from xensource
> repository. We have not tried with PAE hypervisor. It is
> not our focus. How desperately would you need us to try PAE?
Interesting. If you boot with dom0_mem=512 and then start a 15GB guest,
do you see problems shrinking the guest's memory?
I'd certainly be interested in hearing whether the problem exists on
PAE.
Ian
> -----Original Message-----
> From: Ian Pratt [mailto:m+Ian.Pratt@cl.cam.ac.uk]
> Sent: Wednesday, May 03, 2006 4:19 PM
> To: Krysan, Susan; xen-devel@lists.xensource.com
> Cc: Subrahmanian, Raj; Vessey, Bruce A; Puthiyaparambil,
> Aravindh; Carb, Brian A; ian.pratt@cl.cam.ac.uk
> Subject: RE: [Xen-devel] xm mem-set causes kernel panic
>
>
> > When I boot the ES7000 with 32 GB of RAM, dom0 is allocated
> almost all
> > of it. I issued an xm mem-set 0 512 command to decrease
> dom0's memory
> > to 512 MB. Using xentop, I see the amount of memory
> allocated to dom0
> > slowly decrease. The kernel panic occurs when dom0's
> memory is around
> > 1 GB. The serial console output is attached. Using SLES10 Beta 11
> > upgraded to xen changeset 9903.
>
> Can you repro this on -unstable? What about with a PAE hypervisor?
>
> Thanks,
> Ian
>
^ permalink raw reply
* Re: Problems booting VM using unified Xen kernel (x86_64)
From: David F. Barrera @ 2006-05-03 21:16 UTC (permalink / raw)
To: xen-devel
In-Reply-To: <44590BAC.3090407@us.ibm.com>
I need to pint out that I am seeing this problem only on an x86_64
machine. i386 is working as expected.
--
Regards,
David F Barrera
Linux Technology Center
Systems and Technology Group, IBM
"The wisest men follow their own direction. "
Euripides
David F. Barrera wrote:
> I am having trouble booting a guest domain using the unified Xen
> kernel (it
> works fine when using the XenU kernel). Whenever I try to create the
> domain, I get
> the following message:
> bl2-1:/tmp/xen # xm create -c vm1.cfg
> Using config file "vm1.cfg".
> Error: (9, 'Bad file descriptor')
>
>
> ---------------------------------
> The build was done using 'make world' and 'make install', and there
> were no
> build errors:
>
> Xen version 3.0-unstable (root@ltc.austin.ibm.com
> <mailto:root@ltc.austin.ibm.com>) (gcc version 3.3.3 (SuSE
> Linux)) Wed May 3 14:23:44 CDT 2006
> Latest ChangeSet: Wed May 3 07:33:01 2006 +0100 9920:915d5af5dc18
> -----------
> 'strace' shows that files are missing:
>
> stat("/usr/lib64/python/xen/xm/signal", 0x7fffffe08e40) = -1 ENOENT
> (No such
> file or directory)
> open("/usr/lib64/python/xen/xm/signal.so", O_RDONLY) = -1 ENOENT (No
> such file
> or directory)
> open("/usr/lib64/python/xen/xm/signalmodule.so", O_RDONLY) = -1 ENOENT
> (No such
> file or directory)
> open("/usr/lib64/python/xen/xm/signal.py", O_RDONLY) = -1 ENOENT (No
> such file
> or directory)
> open("/usr/lib64/python/xen/xm/signal.pyc", O_RDONLY) = -1 ENOENT (No
> such file
> or directory)
> futex(0x501680, FUTEX_WAKE, 1) = 0
> write(2, "Error:", 6Error:) = 6
> write(2, " ", 1 ) = 1
> write(2, "(9, \'Bad file descriptor\')", 26(9, 'Bad file descriptor'))
> = 26
> write(2, "\n", 1
>
> ----------------------------------------
>
> domU config file:
>
> kernel = "/boot/vmlinuz-2.6-xen"
> # Optional ramdisk.
> ramdisk = "/boot/initrd-2.6.16-xen"
> # The domain build function. Default is 'linux'.
> builder='linux'
> # Initial memory allocation (in megabytes) for the new domain.
> memory = 256
> # A name for your domain. All domains must have different names.
> name = "vm1"
> disk = [ 'phy:sdb3,0813,w','phy:sdb2,0812,w' ]
> # Set if you want dhcp to allocate the IP address.
> # vif = [ 'mac= AA:00:00:47:CB:34, bridge=xen-br0' ]
> vif = [ '' ]
> # Set root device.
> root = "/dev/sdb3 ro"
>
^ permalink raw reply
* [PATCH][SVM][1/2] fix SVM 64bit hv cores>0 reboot/hang issue
From: Woller, Thomas @ 2006-05-03 21:17 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 2578 bytes --]
SVM patch for 64bit hv, to reset the ss, es, ds host selectors to NULL
during a context switch to the SVM domain's vcpu. More detailed
description of the problem below, any alternate solutions and thoughts
are appreciated.
This patch also initializes the tlb_control to 1 for the initial
do_launch().
Applies cleanly to 9906.
Please apply.
Signed-off-by: Tom Woller <thomas.woller@amd.com>
NOTES:
This issue occurs when creating an unmodified HVM/SVM guest on cores>0,
with a 64bit hypervisor, and SMP Dom0. The system will reboot or hang
on the initial vmrun/launch".
The reboot has been traced to a microcode induced processor shutdown.
The shutdown is triggered when the host selectors are being restored
during the initial "vmexit". The microcode performs a consistency check
on each host selector restored. Each selectors' GDT entry being
restored must be accessible to the core performing the VMRUN/VMEXIT. In
this failing case the host selectors being restored are DS/ES == 0x2B
(from Dom0 vcpu), and are contained in physical GDT pages/entries that
are not present in memory for core 1 - which results in a processor
shutdown.
Basically, each host selector that is restored (during a SVM VMEXIT)
must be accessible - i.e. those GDT pages must be mapped in for the core
performing the vmexit. A NULL selector is not checked.
An alternate solution (besides setting ss,es,ds to NULL) would be to
determine where to place code that will ensure that each required GDT
page, associated with the host selectors to be restored, is valid and
physically present. Are ss, es, ds set to 0x2B needed in this 64bit
context, or is the solution of setting these selectors to NULL
sufficient?
We placed test code, into the svm_ctxt_switch_to() function, that
touches each GDT page, but this code is running in Interrupt context,
so page faults result in a CPU1 FATAL TRAP 14 (page fault) during
INTERRUPT CONTEXT.
We also tried running this same test code during the svm do_launch() but
the result is a GP fault and system crash also.
Now, cursory testing on VT boxes indicates that the 0x2B selectors are
also restored on VMX, but the VT microcode does not seem to validate
these values, and therefore does not cause a processor shutdown.
These registers are officially ignored in 64bit mode, and zero'ing them
out seems to be a solution that is functional, but we're unsure as to
the use of the __USER_DS 0x2B values in ds, es selectors in 64bit mode.
Appreciate any information/thoughts,
Tom
[-- Attachment #2: svm_selinit0_9908.patch --]
[-- Type: application/octet-stream, Size: 1676 bytes --]
# HG changeset patch
# User root@xen-trw2.amd
# Node ID d7cc66e6d8eda1f68cb7db5c7964897e08fb00ed
# Parent 70b8ce569a5a5bba96040130af4e50d1fcb1641b
fix SVM core>0 reboot/hang issue by setting es,ss,ds host selectors to NULL
in SVM context_to switch. The entries of the GDT that need to be accessed
in the failing case (in this case selector 0x2B), are not present in memory.
Also, set the tlb flush control to enabled for initial do_launch.
diff -r 70b8ce569a5a -r d7cc66e6d8ed xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c Tue May 2 09:18:14 2006
+++ b/xen/arch/x86/hvm/svm/svm.c Wed May 3 00:56:35 2006
@@ -61,6 +61,9 @@
/* Useful define */
#define MAX_INST_SIZE 15
+#define set_segment_register(name, value) \
+ __asm__ __volatile__ ( "movw %%ax ,%%" STR(name) "" : : "a" (value) )
+
/*
* External functions, etc. We should move these to some suitable header file(s) */
@@ -691,6 +694,17 @@
static void svm_ctxt_switch_to(struct vcpu *v)
{
+#if __x86_64__
+ /*
+ * This is required, because VMRUN does consistency check
+ * and some of the DOM0 selectors are pointing to
+ * invalid GDT locations, and cause AMD processors
+ * to shutdown.
+ */
+ set_segment_register(ds, 0);
+ set_segment_register(es, 0);
+ set_segment_register(ss, 0);
+#endif
}
void svm_final_setup_guest(struct vcpu *v)
diff -r 70b8ce569a5a -r d7cc66e6d8ed xen/arch/x86/hvm/svm/vmcb.c
--- a/xen/arch/x86/hvm/svm/vmcb.c Tue May 2 09:18:14 2006
+++ b/xen/arch/x86/hvm/svm/vmcb.c Wed May 3 00:56:35 2006
@@ -455,6 +455,8 @@
if (svm_dbg_on)
svm_dump_vmcb(__func__, vmcb);
+
+ vmcb->tlb_control = 1;
}
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [PATCH][SVM][2/2] cleanup SVM host save area
From: Woller, Thomas @ 2006-05-03 21:17 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
SVM patch to cleanup the host save area allocation and deallocation,
including removing memory leaks concerning these areas. Also fixes
problem where the HSA MSR was not initialized properly for cores>0.
Applies cleanly to 9906.
Please apply.
Signed-off-by: Tom Woller <thomas.woller@amd.com>
[-- Attachment #2: svm_hsa_9909.patch --]
[-- Type: application/octet-stream, Size: 7516 bytes --]
# HG changeset patch
# User root@xen-trw2.amd
# Node ID b93c4afff94cb15d5cc344182e21817892b1e095
# Parent d7cc66e6d8eda1f68cb7db5c7964897e08fb00ed
Added code to alloc/dealloc HSA per core.
Update the HSA at each resume.
Added missing selectors in save/restore, and consolidate functions.
diff -r d7cc66e6d8ed -r b93c4afff94c xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c Wed May 3 00:56:35 2006
+++ b/xen/arch/x86/hvm/svm/svm.c Wed May 3 01:02:19 2006
@@ -82,6 +82,8 @@
static void svm_relinquish_guest_resources(struct domain *d);
+/* Host save area */
+struct host_save_area *host_save_area[ NR_CPUS ] = {0};
static struct asid_pool ASIDpool[NR_CPUS];
/*
@@ -188,11 +190,16 @@
void stop_svm(void)
{
u32 eax, edx;
+ int cpu = smp_processor_id();
/* We turn off the EFER_SVME bit. */
rdmsr(MSR_EFER, eax, edx);
eax &= ~EFER_SVME;
wrmsr(MSR_EFER, eax, edx);
+
+ /* release the HSA */
+ free_host_save_area( host_save_area[ cpu ] );
+ host_save_area[ cpu ] = NULL;
printk("AMD SVM Extension is disabled.\n");
}
@@ -434,8 +441,11 @@
int start_svm(void)
{
u32 eax, ecx, edx;
-
- /* Xen does not fill x86_capability words except 0. */
+ u32 phys_hsa_lo, phys_hsa_hi;
+ u64 phys_hsa;
+ int cpu = smp_processor_id();
+
+ /* Xen does not fill x86_capability words except 0. */
ecx = cpuid_ecx(0x80000001);
boot_cpu_data.x86_capability[5] = ecx;
@@ -446,7 +456,14 @@
eax |= EFER_SVME;
wrmsr(MSR_EFER, eax, edx);
asidpool_init(smp_processor_id());
- printk("AMD SVM Extension is enabled for cpu %d.\n", smp_processor_id());
+ printk("AMD SVM Extension is enabled for cpu %d.\n", cpu );
+
+ /* Initialize the HSA for this core */
+ host_save_area[ cpu ] = alloc_host_save_area();
+ phys_hsa = (u64) virt_to_maddr( host_save_area[ cpu ] );
+ phys_hsa_lo = (u32) phys_hsa;
+ phys_hsa_hi = (u32) (phys_hsa >> 32);
+ wrmsr(MSR_K8_VM_HSAVE_PA, phys_hsa_lo, phys_hsa_hi);
/* Setup HVM interfaces */
hvm_funcs.disable = stop_svm;
@@ -549,20 +566,6 @@
ctxt->ds = vmcb->ds.sel;
}
-#if defined (__x86_64__)
-void svm_store_cpu_user_regs(struct cpu_user_regs *regs, struct vcpu *v )
-{
- struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
-
- regs->rip = vmcb->rip;
- regs->rsp = vmcb->rsp;
- regs->rflags = vmcb->rflags;
- regs->cs = vmcb->cs.sel;
- regs->ds = vmcb->ds.sel;
- regs->es = vmcb->es.sel;
- regs->ss = vmcb->ss.sel;
-}
-#elif defined (__i386__)
void svm_store_cpu_user_regs(struct cpu_user_regs *regs, struct vcpu *v)
{
struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
@@ -574,11 +577,11 @@
regs->ds = vmcb->ds.sel;
regs->es = vmcb->es.sel;
regs->ss = vmcb->ss.sel;
-}
-#endif
+ regs->fs = vmcb->fs.sel;
+ regs->gs = vmcb->gs.sel;
+}
/* XXX Use svm_load_cpu_guest_regs instead */
-#if defined (__i386__)
void svm_load_cpu_user_regs(struct vcpu *v, struct cpu_user_regs *regs)
{
struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
@@ -591,30 +594,17 @@
vmcb->rflags = regs->eflags;
vmcb->cs.sel = regs->cs;
vmcb->rip = regs->eip;
+
+ vmcb->ds.sel = regs->ds;
+ vmcb->es.sel = regs->es;
+ vmcb->fs.sel = regs->fs;
+ vmcb->gs.sel = regs->gs;
+
if (regs->eflags & EF_TF)
*intercepts |= EXCEPTION_BITMAP_DB;
else
*intercepts &= ~EXCEPTION_BITMAP_DB;
}
-#else /* (__i386__) */
-void svm_load_cpu_user_regs(struct vcpu *v, struct cpu_user_regs *regs)
-{
- struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
- u32 *intercepts = &v->arch.hvm_svm.vmcb->exception_intercepts;
-
- /* Write the guest register value into VMCB */
- vmcb->rax = regs->rax;
- vmcb->ss.sel = regs->ss;
- vmcb->rsp = regs->rsp;
- vmcb->rflags = regs->rflags;
- vmcb->cs.sel = regs->cs;
- vmcb->rip = regs->rip;
- if (regs->rflags & EF_TF)
- *intercepts |= EXCEPTION_BITMAP_DB;
- else
- *intercepts &= ~EXCEPTION_BITMAP_DB;
-}
-#endif /* !(__i386__) */
int svm_paging_enabled(struct vcpu *v)
{
@@ -749,10 +739,6 @@
{
if ( !test_bit(_VCPUF_initialised, &v->vcpu_flags) )
continue;
-#if 0
- /* Memory leak by not freeing this. XXXKAF: *Why* is not per core?? */
- free_host_save_area(v->arch.hvm_svm.host_save_area);
-#endif
destroy_vmcb(&v->arch.hvm_svm);
free_monitor_pagetable(v);
diff -r d7cc66e6d8ed -r b93c4afff94c xen/arch/x86/hvm/svm/vmcb.c
--- a/xen/arch/x86/hvm/svm/vmcb.c Wed May 3 00:56:35 2006
+++ b/xen/arch/x86/hvm/svm/vmcb.c Wed May 3 01:02:19 2006
@@ -36,9 +36,11 @@
#include <xen/kernel.h>
#include <xen/domain_page.h>
+extern struct host_save_area *host_save_area[];
extern int svm_dbg_on;
extern int asidpool_assign_next( struct vmcb_struct *vmcb, int retire_current,
int oldcore, int newcore);
+extern void set_hsa_to_guest( struct arch_svm_struct *arch_svm );
#define round_pgdown(_p) ((_p)&PAGE_MASK) /* coped from domain.c */
@@ -309,8 +311,6 @@
{
int error;
long rc=0;
- struct host_save_area *hsa = NULL;
- u64 phys_hsa;
memset(arch_svm, 0, sizeof(struct arch_svm_struct));
@@ -320,36 +320,9 @@
goto err_out;
}
- /*
- * The following code is for allocating host_save_area.
- * Note: We either allocate a Host Save Area per core or per VCPU.
- * However, we do not want a global data structure
- * for HSA per core, we decided to implement a HSA for each VCPU.
- * It will waste space since VCPU number is larger than core number.
- * But before we find a better place for HSA for each core, we will
- * stay will this solution.
- */
-
- if (!(hsa = alloc_host_save_area()))
- {
- printk("Failed to allocate Host Save Area\n");
- rc = -ENOMEM;
- goto err_out;
- }
-
- phys_hsa = (u64) virt_to_maddr(hsa);
- arch_svm->host_save_area = hsa;
- arch_svm->host_save_pa = phys_hsa;
-
+ /* update the HSA for the current Core */
+ set_hsa_to_guest( arch_svm );
arch_svm->vmcb_pa = (u64) virt_to_maddr(arch_svm->vmcb);
-
- if ((error = load_vmcb(arch_svm, arch_svm->host_save_pa)))
- {
- printk("construct_vmcb: load_vmcb failed: VMCB = %lx\n",
- (unsigned long) arch_svm->host_save_pa);
- rc = -EINVAL;
- goto err_out;
- }
if ((error = construct_vmcb_controls(arch_svm)))
{
@@ -460,18 +433,11 @@
}
-int load_vmcb(struct arch_svm_struct *arch_svm, u64 phys_hsa)
-{
- u32 phys_hsa_lo, phys_hsa_hi;
-
- phys_hsa_lo = (u32) phys_hsa;
- phys_hsa_hi = (u32) (phys_hsa >> 32);
-
- wrmsr(MSR_K8_VM_HSAVE_PA, phys_hsa_lo, phys_hsa_hi);
- set_bit(ARCH_SVM_VMCB_LOADED, &arch_svm->flags);
- return 0;
-}
-
+void set_hsa_to_guest( struct arch_svm_struct *arch_svm )
+{
+ arch_svm->host_save_area = host_save_area[ smp_processor_id() ];
+ arch_svm->host_save_pa = (u64)virt_to_maddr( arch_svm->host_save_area );
+}
/*
* Resume the guest.
@@ -483,6 +449,9 @@
struct hvm_time_info *time_info = &vpit->time_info;
svm_stts(v);
+
+ /* make sure the HSA is set for the current core */
+ set_hsa_to_guest( &v->arch.hvm_svm );
/* pick up the elapsed PIT ticks and re-enable pit_timer */
if ( time_info->first_injected ) {
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* DMA remap_pfn_range VM_IO pci_map_sg
From: Ice Cold @ 2006-05-03 21:18 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1146690339.515246.155630@u72g2000cwu.googlegroups.com>
Hi Group,
I have a few fundamental DMA questions which i need help with. These
are all relating to kernel 2.6+.
I have 40 megs of memory set aside for DMA. (This is an embedded device
so i can afford to do this). This memory is set aaside using the mem= option
on the boot line. I need to DMA data to parts of this memory. The DMA card
is a PCI based card with no addressing limitations. I want to make use of
the 2.6DMA API.
The reserved memory is given to anyone who requests it via the MMAP
call, internally it uses remap_pfn_range to fix up the page tables.
Call sequence.
1. Userspace mmaps a large chuck on this memory, and then breaks it up
intoa chunk, and wants to DMA data from the imaging device to this chunck.
2. It fires an IOCTL to my driver passing a start pointer to this chunk
and the len.
In the driver, i want to be able to
1. Create a scatter gather list for this chunk.
2. use pci_map_sg to map these pages.
3. use sg_address and sg_len to get the bus addresses.
4. using the bus address i want to populate the datastructures for this
card and start the DMA.
Questions.
1. To generate the scatter gather list, i need to get a list of pages
for the memory region passed to me? How do i do that? i know
get_user_pages cannot be called since it does not work on VM_IO
regions and remap_pfn_range marks the vma as VM_IO.
2. Is there any sample driver you know of which does similar stuff?
I'm open to suggestions and ideas.
rcn
^ permalink raw reply
* [Qemu-devel] qemu vnc.c
From: Fabrice Bellard @ 2006-05-03 21:18 UTC (permalink / raw)
To: qemu-devel
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Fabrice Bellard <bellard@savannah.gnu.org> 06/05/03 21:18:59
Modified files:
. : vnc.c
Log message:
removed ssize_t for win32 compatibility
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vnc.c.diff?tr1=1.4&tr2=1.5&r1=text&r2=text
^ permalink raw reply
* latest -stable breaks Squid
From: Dave Jones @ 2006-05-03 21:19 UTC (permalink / raw)
To: netdev; +Cc: stable, Andreas M. Kirchwitz, Vassilios Kotoulas
[-- Attachment #1: Type: text/plain, Size: 290 bytes --]
So I pushed out an update for Fedora Core 5 users yesterday
that moved the kernel from 2.6.16.9 to 2.6.16.13.
I've since heard "My network performance is awful", and worse
yet, some apps seem broken as in the report below.
Anyone have any ideas ?
Dave
--
http://www.codemonkey.org.uk
[-- Attachment #2: Type: message/rfc822, Size: 4270 bytes --]
From: "Andreas M. Kirchwitz" <fedora-list@list.zikzak.de>
To: fedora-list@redhat.com
Subject: Kernel 2.6.16-1.2107_FC5 breaks Squid
Date: Wed, 3 May 2006 12:53:04 +0000 (UTC)
Message-ID: <slrne5h9tg.or2.amk@nautilus.zikzak.de>
Hi folks!
Just installed the new kernel 2.6.16-1.2107_FC5 (32-bit, i686),
and everything seems to work fine -- except Squid (not matter
if I use the one that ships with FC5 or my own).
No problem with small data objects (a few kilobytes).
telnet localhost 3128
GET http://www.kirchwitz.de/test.html HTTP/1.0
Large data objects won't work. According to ethereal, the data
is loaded successfully. And I also find the complete objects
in /var/spool/squid, but the data is not output to the application:
telnet localhost 3128
GET http://www.heise.de/ HTTP/1.0
After a few kilobytes, the stream suddenly stops. Sometimes,
Squid doesn't do any output at all, although the object is in
the cache.
With the previous kernel 2.6.16-1.2096_FC5 all is well.
What has changed in the kernel that makes Squid break so hardly?
Maybe other applications are affected as well. Don't know yet.
The error with squid was simply very obvious. ;-)
Greetings, Andreas
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
^ permalink raw reply
* Re: Problem using GIT CVS-server
From: Junio C Hamano @ 2006-05-03 21:21 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605031412s363b4a79p548c75956b00adbf@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
>> Could you see if the attached patch helps?
>
> Will try it in a moment. Having thought about it, git-log is always
> going to be tweaked for human consumption, so I should use something
> geared for porcelains instead. git-rev-list does honour --parent, so
> perhaps I should switch to using that instead?
I think that reasoning is prudent, but at the same time I think
the patch by Linus is also right, so I think we should do both
for this particular case.
Sorry about the breakage.
^ permalink raw reply
* Where to look for CRAMFS
From: Sauro Salomoni @ 2006-05-03 21:15 UTC (permalink / raw)
To: linuxppc-embedded
Greetings.
I have an embedded board using i.MX21.
What I want to know is: how do I tell the kernel where my CRAMFS root
file system is?
I mean, I put it in a specific memory address, but how does the kernel
know where it is?!
What happens here is that the kernel looks in some address and don't
find the Magic Number CRAMFS stores in its own start address. I have a
"bad magic number" msg because my root fs is somewhere else.
Can anyone help me, plz?
Thanks in advance.
Sauro
Engineer
Z Tec
www.ztec.com.br
+55 61 3322-2544
^ permalink raw reply
* conntrack sync via userspace ?
From: Arne Bernin @ 2006-05-03 21:22 UTC (permalink / raw)
To: netfilter-devel
Hi all,
after playing a bit with ct_sync and finding out that it does not seems
being actively developed i wonder whether it would be possible to do the
syncing of conntrack tables over different machines using a user space
daemon and libnfnetfilter_conntrack ? Is this a possible way , or a no
go because of limitations in the conntrack lib , speed or something else
i am not aware of ?
I thought before digging to deep into it right now, i just ask the
people who should know, sorry about my lazyness. ;-)
--arne
--
Arne Bernin <arne@alamut.de>
http://www.ucBering.de
^ permalink raw reply
* [Qemu-devel] qemu/pc-bios bios.bin bios.diff
From: Fabrice Bellard @ 2006-05-03 21:24 UTC (permalink / raw)
To: qemu-devel
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Fabrice Bellard <bellard@savannah.gnu.org> 06/05/03 21:24:55
Modified files:
pc-bios : bios.bin bios.diff
Log message:
more correct e820 ranges for ACPI compatibility
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/pc-bios/bios.bin.diff?tr1=1.13&tr2=1.14&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/pc-bios/bios.diff.diff?tr1=1.11&tr2=1.12&r1=text&r2=text
^ permalink raw reply
* Re:
From: tom arnall @ 2006-05-03 21:28 UTC (permalink / raw)
To: linux-admin
In-Reply-To: <4457BC2F.4010208@tessco.com>
my system freezes when I try to run an application that handles a large file
in a variable. I have set ulimits as follows:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 256000
max memory size (kbytes, -m) 256000
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
Physical memory on the system is 512MB, yet when the application runs -
despite the limits shown above - linux hands almost all of memory to the
application.
Tom Arnall
north spit, ca
^ permalink raw reply
* [PATCH] blame: Fix path pruning
From: Fredrik Kuivinen @ 2006-05-03 21:28 UTC (permalink / raw)
To: git; +Cc: junkio
This makes git-blame useable again, it has been totally broken for
some time on larger repositories.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
blame.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/blame.c b/blame.c
index 07d2d27..99ceea8 100644
--- a/blame.c
+++ b/blame.c
@@ -515,9 +515,9 @@ static int compare_tree_path(struct rev_
paths[1] = NULL;
diff_tree_setup_paths(get_pathspec(revs->prefix, paths),
- &revs->diffopt);
+ &revs->pruning);
ret = rev_compare_tree(revs, c1->tree, c2->tree);
- diff_tree_release_paths(&revs->diffopt);
+ diff_tree_release_paths(&revs->pruning);
return ret;
}
@@ -531,9 +531,9 @@ static int same_tree_as_empty_path(struc
paths[1] = NULL;
diff_tree_setup_paths(get_pathspec(revs->prefix, paths),
- &revs->diffopt);
+ &revs->pruning);
ret = rev_same_tree_as_empty(revs, t1);
- diff_tree_release_paths(&revs->diffopt);
+ diff_tree_release_paths(&revs->pruning);
return ret;
}
@@ -834,7 +834,7 @@ int main(int argc, const char **argv)
args[0] = filename;
args[1] = NULL;
- diff_tree_setup_paths(args, &rev.diffopt);
+ diff_tree_setup_paths(args, &rev.pruning);
prepare_revision_walk(&rev);
process_commits(&rev, filename, &initial);
^ permalink raw reply related
* Re: xm mem-set causes kernel panic
From: Andrew Theurer @ 2006-05-03 21:29 UTC (permalink / raw)
To: Krysan, Susan
Cc: Ian Pratt, xen-devel, Puthiyaparambil, Aravindh,
Subrahmanian, Raj, Vessey, Bruce A, Carb, Brian A
In-Reply-To: <EF8D308BE33AF54D8934DF26520252D303504211@USTR-EXCH5.na.uis.unisys.com>
Krysan, Susan wrote:
> We did run using unstable. We installed sles10 beta11 but we pulled and built xen-unstable changeset 9903 from xensource repository. We have not tried with PAE hypervisor. It is not our focus. How desperately would you need us to try PAE?
>
I have done this on 32GB x86_64 as well and have pretty much the same
problem. I think the problem is that the static memory allocations in
the kernel for things like mem_map, page_struct etc, are quite large for
32GB, and do not shrink (or do they?) when balooning to 512 MB. This
leaves almost no usable memory when balooning down, and you get OOM. If
you know you don't need 32G for dom0, I would try setting dom0_mem to
something much lower, like 1GB.
-Andrew Theurer
> Thanks,
>
>
>> Sue Krysan
>> Linux Systems Group
>> Unisys Corporation
>>
>>
>
>
> -----Original Message-----
> From: Ian Pratt [mailto:m+Ian.Pratt@cl.cam.ac.uk]
> Sent: Wednesday, May 03, 2006 4:19 PM
> To: Krysan, Susan; xen-devel@lists.xensource.com
> Cc: Subrahmanian, Raj; Vessey, Bruce A; Puthiyaparambil, Aravindh; Carb,
> Brian A; ian.pratt@cl.cam.ac.uk
> Subject: RE: [Xen-devel] xm mem-set causes kernel panic
>
>
>
>> When I boot the ES7000 with 32 GB of RAM, dom0 is allocated
>> almost all of it. I issued an xm mem-set 0 512 command to
>> decrease dom0's memory to 512 MB. Using xentop, I see the
>> amount of memory allocated to dom0 slowly decrease. The
>> kernel panic occurs when dom0's memory is around 1 GB. The
>> serial console output is attached. Using SLES10 Beta 11
>> upgraded to xen changeset 9903.
>>
>
> Can you repro this on -unstable? What about with a PAE hypervisor?
>
> Thanks,
> Ian
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
^ permalink raw reply
* netlink+ARP+CLIP == broken,
From: Simon Kelley @ 2006-05-03 21:32 UTC (permalink / raw)
To: netdev, linux-kernel
Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with
family == AF_INET. For most purposes this is fine, since the two modules
each hold a pointer to their table and pass it into the neigh_* functions.
A problem arises in neigh_add, which is called by the rtnetlink code and
which iterates through all the neighbour tables looking for the first
one with the correct family. Since there are two different tables with
family == AF_INET, sometimes it picks the wrong one.
This leads to the situation where sending a RTM_NEWNEIGH message via
netlink can generate an ignored and useless entry in the clip table,
whilst the not affecting another entry in the ARP table, both entries
for the same IP.
Viz:
sid:~# ip neigh
192.168.3.40 dev eth0 lladdr 52:54:00:12:34:59 REACHABLE
192.168.3.40 dev eth0 FAILED
It's not immediately obvious how to fix this in a conceptually clean
manner: neighbour tables are not associated with single netdevices, and
they don't carry an address-type field. Given a {IP,lladdr,device}
triple, its easy to determine if the device is ether-like or CLIP, but
then the update call would have to go via the ARP and CLIP modules,
instead of direct to the neighbour module in an address independent way.
New address types would need further additions to the netlink/neighbour
code.
OTOH there are several obvious hacks that will fix the immediate
problem. I'm happy to provide a patch implementing one if that's desired.
Looking again, I think this is also a security hole, since the CLIP code
keeps a whole struct including pointers in the neighbour table entry
where ARP has the MAC address. So this might provide a way to poke
arbitrary pointers into the kernel via RTM_NEWNEIGH. Only for root, though.
Cheers,
Simon.
^ permalink raw reply
* Re: Problems with EDAC coexisting with BIOS
From: Alan Cox @ 2006-05-03 21:44 UTC (permalink / raw)
To: Tim Small
Cc: Ong, Soo Keong, Gross, Mark, bluesmoke-devel, LKML,
Carbonari, Steven, Wang, Zhenyu Z
In-Reply-To: <4459119D.10905@buttersideup.com>
On Mer, 2006-05-03 at 21:25 +0100, Tim Small wrote:
> something with NMI-signalled errors, I was wondering what the problems
> with using NMI-signalled ECC errors were?
The big problem with NMI is that it can occur *during* a PCI
configuration sequence (ie during pci_config_* functions). That means we
can't safely do some I/O, especially configuration space I/O in an NMI
handler. At best we could set a flag and catch it afterwards.
^ permalink raw reply
* Re: [stable] Re: Linux 2.6.16.13 / Problem
From: Greg KH @ 2006-05-03 21:34 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: stable, ja, gregkh, torvalds, linux-kernel
In-Reply-To: <20060503230906.82e0c9f2.skraw@ithnet.com>
On Wed, May 03, 2006 at 11:09:06PM +0200, Stephan von Krawczynski wrote:
> On Wed, 3 May 2006 11:54:09 -0700
> Greg KH <greg@kroah.com> wrote:
>
> > On Wed, May 03, 2006 at 03:45:32PM +0200, Stephan von Krawczynski wrote:
> > > Hi Greg,
> > >
> > > unfortunately I see some problem regarding 2.6.16.13:
> >
> > Makes sense, as nothing in .13 was for something like this :)
>
> Sorry, didn't get that joke (no native englishman), you may explain in private
> to me having spare time. Do you mean this is a _new_ story completely
> unrelated to .13?
No, meaning that .13 fixed a totally different problem from what you are
reporting, so it is expected that the same problem you see with .12 is
also in .13.
thanks,
greg k-h
^ 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.