On 15/07/15 10:52, Konstantin Khlebnikov wrote:
This code is used only when CONFIG_PREEMPT=n and only in non-atomic context:
xen_in_preemptible_hcall is set only in privcmd_ioctl_hypercall().
Thus preempt_count is zero and should_resched() is equal to need_resched().
Applied to for-linus-4.3,
On 07/04/15 03:55, Waiman Long wrote:
This patch adds the necessary Xen specific code to allow Xen to
support the CPU halting and kicking operations needed by the queue
spinlock PV code.
This basically looks the same as the version I wrote, except I think you
broke it.
+static void
to disable QUEUE_SPINLOCKS when supported by
the arch, is this intentional? If so, the existing ticketlock code could go.
David
8--
x86/xen: paravirt support for qspinlocks
Provide the wait and kick ops necessary for paravirt-aware queue
spinlocks.
Signed-off-by: David
On 16/03/15 13:16, Peter Zijlstra wrote:
Hi Waiman,
As promised; here is the paravirt stuff I did during the trip to BOS last
week.
All the !paravirt patches are more or less the same as before (the only real
change is the copyright lines in the first patch).
The paravirt stuff is
) {
add_stats(RELEASED_SLOW_KICKED, 1);
xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
break;
Acked-by: David Vrabel david.vra...@citrix.com
Although some of the ACCESS_ONCE to READ_ONCE changes are cosmetic and
are perhaps best left out
On 27/01/15 01:51, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v5 nukes tracing as David said it was useless, it also
only adds support for 64-bit as its the only thing I can test,
and slightly modifies the documentation in code as to why we
want this. The no krobe
On 27/01/15 01:51, Luis R. Rodriguez wrote:
+#ifndef CONFIG_PREEMPT
+extern struct { char _entry[32]; } preemptible_hypercall_page[];
+
+static inline bool xen_is_preemptible_hypercall(struct pt_regs *regs)
+{
+ return !user_mode_vm(regs)
+ regs-ip = (unsigned
On 03/02/15 00:24, Luis R. Rodriguez wrote:
As I waited I decided to finally install a 32-bit OS but I found now
that as of Xen commit 5d1181a5 which went upstream as of xen 4.3 Xen
no longer supports 32-bit for x86.
You don't need a 32-bit hypervisor to run 32-bit dom0 or domUs.
David
--
On 27/01/15 08:35, Jan Beulich wrote:
On 27.01.15 at 02:51, mcg...@do-not-panic.com wrote:
Even if David told you this would be acceptable, I have to question
an abstract model of fixing issues on only 64-bit kernels - this may
be acceptable for distro purposes, but seems hardly the right
On 23/01/15 18:58, Luis R. Rodriguez wrote:
Its not just hypercalls though, this is all about the interactions
with multicalls no?
No. This applies to any preemptible hypercall and the toolstack doesn't
use multicalls for most of its work.
David
--
To unsubscribe from this list: send the
On 23/01/15 00:29, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Xen has support for splitting heavy work work into a series
of hypercalls, called multicalls, and preempting them through
what Xen calls continuation [0]. Despite this though without
CONFIG_PREEMPT
On 23/01/15 00:29, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v4 addresses some of the cleanups recommended and adds
tracing option for when we do actually preempt a hypercall.
I kept the NOKPROBE_SYMBOL() for now but did remove the 'notrace'
stuff.
This goes
On 23/01/15 00:29, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
On kernels with voluntary or no preemption we can run
into situations where a hypercall issued through userspace
will linger around as it addresses sub-operatiosn in kernel
context (multicalls). Such
On 22/01/15 03:18, Andy Lutomirski wrote:
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -32,6 +32,8 @@
#include linux/slab.h
#include linux/irqnr.h
#include linux/pci.h
+#include linux/sched.h
+#include linux/kprobes.h
#ifdef CONFIG_X86
#include
On 20/01/15 20:12, Waiman Long wrote:
This patch adds the necessary XEN specific code to allow XEN to
support the CPU halting and kicking operations needed by the queue
spinlock PV code.
Xen is a word, please don't capitalize it.
+void xen_lock_stats(int stat_types)
+{
+ if (stat_types
)
Change the p2m code to replace ACCESS_ONCE with READ_ONCE.
Acked-by: David Vrabel david.vra...@citrix.com
Let me know if you want me to merge this via the Xen tree.
David
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
)
Change the p2m code to replace ACCESS_ONCE with READ_ONCE.
Acked-by: David Vrabel david.vra...@citrix.com
Let me know if you want me to merge this via the Xen tree.
David
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More
-by: David Vrabel david.vra...@citrix.com
But see some additional comments below.
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info
*get_pvti(int cpu)
static notrace cycle_t vread_pvclock(int *mode
On 23/12/14 00:39, Andy Lutomirski wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.
On 01/12/14 22:36, Luis R. Rodriguez wrote:
Then I do agree its a fair analogy (and find this obviously odd that how
widespread cond_resched() is), we just don't have an equivalent for IRQ
context, why not avoid the special check then and use this all the time in the
middle of a hypercall on
On 28/11/14 04:49, Juergen Gross wrote:
On 11/27/2014 07:50 PM, Andrew Cooper wrote:
XenServer uses
https://github.com/xenserver/linux-3.x.pg/blob/master/master/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
to deal with these issues. That patch is based on 3.10.
Clever.
On 27/11/14 18:36, Luis R. Rodriguez wrote:
On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Some folks had reported that some xen hypercalls take a long time
to complete when issued from
On 01/12/14 15:05, Luis R. Rodriguez wrote:
On Mon, Dec 01, 2014 at 11:11:43AM +, David Vrabel wrote:
On 27/11/14 18:36, Luis R. Rodriguez wrote:
On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg
On 01/12/14 15:44, Luis R. Rodriguez wrote:
On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel david.vra...@citrix.com wrote:
On 01/12/14 15:05, Luis R. Rodriguez wrote:
On Mon, Dec 01, 2014 at 11:11:43AM +, David Vrabel wrote:
On 27/11/14 18:36, Luis R. Rodriguez wrote:
On Thu, Nov 27, 2014
On 01/12/14 16:19, Luis R. Rodriguez wrote:
On Mon, Dec 01, 2014 at 03:54:24PM +, David Vrabel wrote:
On 01/12/14 15:44, Luis R. Rodriguez wrote:
On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel david.vra...@citrix.com
wrote:
On 01/12/14 15:05, Luis R. Rodriguez wrote:
On Mon, Dec 01, 2014
On 29/10/14 05:19, Andy Lutomirski wrote:
CPUID leaf 4F02H: miscellaneous features
[...]
### CommonHV RNG
If CPUID.4F02H.EAX is nonzero, then it contains an MSR index used to
communicate with a hypervisor random number generator. This
On 29/10/14 13:45, Paolo Bonzini wrote:
On 10/29/2014 11:37 AM, Andrew Cooper wrote:
While testing various nested combinations, XenServer has found that
modern Windows Server versions must have the hypervisor bit hidden from
them for them to be happy running HyperV, despite the fact that
with this flag on Xen since we never
use it but:
Acked-by: David Vrabel david.vra...@citrix.com
I'm expecting this to go via the PCI tree.
David
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -133,7 +133,7 @@ static void pcistub_device_release(struct kref
On 11/07/14 06:52, Ethan Zhao wrote:
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -133,7 +133,7 @@ static void pcistub_device_release(struct kref *kref)
xen_pcibk_config_free_dyn_fields(dev);
xen_pcibk_config_free_dev(dev);
-
On 15/02/14 02:59, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v2 series changes the approach from my original virtualization
multicast patch series [0] by abandoning completely the multicast
issues and instead generalizing an approach for virtualization
backends.
On 15/02/14 02:59, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
The purpose of using a static MAC address of FE:FF:FF:FF:FF:FF
was to prevent our backend interfaces from being used by the
bridge and nominating our interface as a root bridge. This was
possible given that
31 matches
Mail list logo
