e
not mergeable.
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
---
drivers/xen/biomerge.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/xen/biomerge.c b/drivers/xen/biomerge.c
index 0edb91c..20387c2 100644
--- a/drivers/xen/biome
On 05/07/2015 11:10 AM, Michal Suchanek wrote:
Hello,
it appears the Linus master tree fails to build on ARM with XEN enabled.
Since commit 2b953a5e9 xen: Suspend ticks on all CPUs during suspend
provides the suspend function only for x86 this is not surprising.
I currently don't use XEN yet
Commit 2b953a5e994c ("xen: Suspend ticks on all CPUs during suspend")
introduced xen_arch_suspend() routine but did so only for x86, breaking
ARM builds.
We need to add it to ARM as well.
Signed-off-by: Boris Ostrovsky
Reported-by: Michal Suchanek
Tested-by: Stefano Stabellini
---
On 05/04/2015 10:46 PM, Hanjun Guo wrote:
In ACPI processor drivers, we use direct comparisons of cpu logical
id with -1 which are error prone in case logical cpuid is accidentally
assinged an error code and prevents us from returning an error-encoding
cpuid directly in some cases.
Which is ex
On 05/05/2015 09:51 AM, Andy Lutomirski wrote:
On Mon, May 4, 2015 at 8:02 AM, Boris Ostrovsky
wrote:
Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
attribute issue") makes AMD processors set SS to __KERNEL_DS in
__switch_to() to deal with cases when SS is N
On 05/05/2015 01:25 PM, David Vrabel wrote:
On 04/05/15 16:02, Boris Ostrovsky wrote:
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1760,6 +1760,9 @@ static struct notifier_block xen_hvm_cpu_notifier = {
static void __init xen_hvm_guest_init(void)
{
+ if
On 05/19/2015 08:58 AM, Arnd Bergmann wrote:
A recent bug fix for x86 broke Xen on ARM for the case that
CONFIG_HIBERNATE_CALLBACKS is enabled:
drivers/built-in.o: In function `do_suspend':
/git/arm-soc/drivers/xen/manage.c:134: undefined reference to `xen_arch_suspend'
drivers/built-in.o:(.debu
On 05/19/2015 10:36 AM, Arnd Bergmann wrote:
On Tuesday 19 May 2015 09:57:19 Boris Ostrovsky wrote:
On 05/19/2015 08:58 AM, Arnd Bergmann wrote:
A recent bug fix for x86 broke Xen on ARM for the case that
CONFIG_HIBERNATE_CALLBACKS is enabled:
drivers/built-in.o: In function `do_suspend
On 05/01/2015 06:46 AM, David Vrabel wrote:
On 29/04/15 22:10, Boris Ostrovsky wrote:
When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt to be claimed by wrong VCPU since
On 05/01/2015 11:25 AM, David Vrabel wrote:
On 01/05/15 14:39, Boris Ostrovsky wrote:
On 05/01/2015 06:46 AM, David Vrabel wrote:
On 29/04/15 22:10, Boris Ostrovsky wrote:
When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level
On 04/30/2015 03:27 AM, Ouyang Zhaowei (Charles) wrote:
On 2015.4.29 5:31, Boris Ostrovsky wrote:
On 04/28/2015 08:30 AM, Ouyang Zhaowei (Charles) wrote:
On 2015.4.26 7:31, Boris Ostrovsky wrote:
On 04/24/2015 05:30 AM, Ouyang Zhaowei (Charles) wrote:
If a PVOPS VM has multi-cpu the
ture is no longer
HVM-specific we should do some renaming).
Signed-off-by: Boris Ostrovsky
Reported-by: Sander Eikelenboom
---
v2:
* Adjusted ifdefs to account for !CONFIG_PVHVM case
* Renamed xen_guest_init() back to xen_hvm_guest_init()
arch/x86/include/asm/hypervisor.h | 2 +-
arch/x86/
ing hook to use - just fit the two together. Note
that the hook can (and should) be used irrespective of whether being in
Dom0, as accessing port 0x61 in a DomU would be even worse, while the
shared info field would just hold zero all the time.
Reviewed-by: Boris Ostrovsky
Signed-off-by: Jan Beul
With 250a1ac685f (x86, smpboot: Remove pointless preempt_disable() in
native_smp_prepare_cpus()) HVM guests no longer boot since we are
hitting BUG_ON(preemptible()) in xen_setup_cpu_clockevents().
I don't think we need this test (PV or HVM), do we?
-boris
--
To unsubscribe from this list: se
There is no reason for having it and, with commit 250a1ac685f1 ("x86,
smpboot: Remove pointless preempt_disable() in
native_smp_prepare_cpus()"), it prevents HVM guests from booting.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/time.c | 2 --
1 file changed, 2 deletions(-)
diff --
On 02/24/2015 01:06 AM, Juergen Gross wrote:
On 02/18/2015 06:02 PM, Boris Ostrovsky wrote:
On 02/17/2015 02:02 AM, Juergen Gross wrote:
When a xen domain is being restored the LUN state of a pvscsi device
is "Connected" and not "Initialising" as in case of attaching a n
On 03/06/2015 08:50 PM, Andy Lutomirski wrote:
I broke 32-bit kernels. The implementation of sp0 was correct as
far as I can tell, but sp0 was much weirder on x86_32 than I
realized. It has the following issues:
- Init's sp0 is inconsistent with everything else's: non-init tasks
are offs
Grall
CC: Konrad Rzeszutek Wilk
CC: Boris Ostrovsky
CC: David Vrabel
Signed-off-by: Hanjun Guo
---
drivers/xen/Kconfig | 4
drivers/xen/Makefile | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index b812462..a31cd29 100644
---
On 03/04/2015 10:25 AM, Paul E. McKenney wrote:
On Wed, Mar 04, 2015 at 09:55:11AM -0500, Boris Ostrovsky wrote:
The simple solution is to stop calling native_cpu_die() above but
I'd like to use common code in native_cpu_die(). I'll see if I can
carve it out without too much dam
On 03/03/2015 12:35 AM, Luis R. Rodriguez wrote:
On Mon, Feb 23, 2015 at 9:09 AM, David Vrabel wrote:
On 23/02/15 16:01, Boris Ostrovsky wrote:
Commit 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
introduced CR4 shadows.
These shadows are initialized in early boot code.
On 03/03/2015 12:42 PM, Paul E. McKenney wrote:
}
@@ -511,7 +508,8 @@ static void xen_cpu_die(unsigned int cpu)
schedule_timeout(HZ/10);
}
- cpu_die_common(cpu);
+ (void)cpu_wait_death(cpu, 5);
+ /* FIXME: Are the below calls really safe in case of timeou
On 03/03/2015 02:42 PM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 02:17:24PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 12:42 PM, Paul E. McKenney wrote:
}
@@ -511,7 +508,8 @@ static void xen_cpu_die(unsigned int cpu)
schedule_timeout(HZ/10
On 03/03/2015 04:26 PM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 03:13:07PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 02:42 PM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 02:17:24PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 12:42 PM, Paul E. McKenney wrote:
}
@@ -511,7
On 03/04/2015 09:43 AM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 02:31:51PM -0800, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 05:06:50PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 04:26 PM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 03:13:07PM -0500, Boris Ostrovsky wrote
On 03/04/2015 10:45 AM, David Vrabel wrote:
On 04/03/15 14:55, Boris Ostrovsky wrote:
In the meantime, it turned out that HVM guests are broken by this patch
(with our without changes that we've been discussing), because HVM CPUs
die with
static void xen_hvm_cpu_die(unsigned in
is bit might be set. Make sure
we clear it before returning MSR value to the caller.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 78a881b.
On 01/22/2015 03:20 AM, Borislav Petkov wrote:
Hmm,
and I thought we fixed all that fun. It seems not :-\
Boris, this paravirt_enabled() thing doesn't seem to work or why are we
even calling microcode_exit()?
Looks like something is unloading microcode driver (init scripts
perhaps) and so we
On 01/22/2015 09:48 AM, Boris Ostrovsky wrote:
On 01/22/2015 03:20 AM, Borislav Petkov wrote:
Hmm,
and I thought we fixed all that fun. It seems not :-\
Boris, this paravirt_enabled() thing doesn't seem to work or why are we
even calling microcode_exit()?
Looks like something is unlo
Commit 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
introduced CR4 shadows.
These shadows are initialized in early boot code. The commit missed
initialization for 64-bit PV(H) guests that this patch adds.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c |1
On 02/23/2015 11:09 AM, Andy Lutomirski wrote:
On Mon, Feb 23, 2015 at 8:01 AM, Boris Ostrovsky
wrote:
Commit 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
introduced CR4 shadows.
These shadows are initialized in early boot code. The commit missed
initialization for 6
On 02/17/2015 02:02 AM, Juergen Gross wrote:
When a xen domain is being restored the LUN state of a pvscsi device
is "Connected" and not "Initialising" as in case of attaching a new
pvscsi LUN.
This must be taken into account when adding a new pvscsi device for
a domain as otherwise the pvscsi L
On 12/11/2014 01:04 PM, Juergen Gross wrote:
diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
new file mode 100644
index 000..e6447b7
--- /dev/null
+++ b/scripts/xen-hypercalls.sh
@@ -0,0 +1,11 @@
+#!/bin/sh
+out="$1"
+shift
+in="$@"
+
+for i in $in; do
+ eval $CPP $LI
On 04/15/2016 06:03 PM, Thomas Garnier wrote:
+void __init kernel_randomize_memory(void)
+{
+ size_t i;
+ unsigned long addr = memory_rand_start;
+ unsigned long padding, rand, mem_tb;
+ struct rnd_state rnd_st;
+ unsigned long remain_padding = memory_rand_end - me
Ping?
On 03/17/2016 09:33 AM, Boris Ostrovsky wrote:
Original version of that patch (commit a89941816726) had to be reverted
due to Xen allocating irqs in its cpu_up ops.
The first patch moves allocations into hotplug notifiers and the second
one restores the original patch (with minor
Original version of that patch (commit a89941816726) had to be reverted
due to Xen allocating irqs in its cpu_up ops.
The first patch moves allocations into hotplug notifiers and the second
one restores the original patch (with minor adjustments to new hotplug
framework)
Boris Ostrovsky (2
become 64K which is
obviously problematic.
While RAPL code (and any other users of logical_package_id) should be
careful in their assumptions about id's validity, Xen's
cpu_present_to_apicid op should still provide value consistent with its
own xen_apic_read(APIC_ID).
Signed-off-by: Boris
Two patches fixing regressions introduced by new CPU hotplug framework
Boris Ostrovsky (2):
xen/apic: Provide Xen-specific version of cpu_present_to_apicid APIC
op
xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from
xen_play_dead()
arch/x86/xen/apic.c | 12
up ops.
We can move those allocations into CPU notifiers so that original
patch can be reinstated.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c | 53 ++---
arch/x86/xen/smp.c | 45 +-
arch/x86/xe
q() may result
in a EVTCHNOP_unmask hypercall which, in turn, may make the event
pending on the target CPU.
We can avoid this situation by moving and clearing the event while
keeping event masked.
Signed-off-by: Boris Ostrovsky
Cc: sta...@vger.kernel.org
---
v2:
* Use irq_move_masked_irq() inst
This call has always been missing from xen_play dead() but until
recently this was rather benign. With new cpu hotplug framework
however this call is required, otherwise a hot-plugged CPU will not
be properly brough up (by never calling cpuhp_online_idle())
Signed-off-by: Boris Ostrovsky
On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote:
We have 4 types of x86 platforms that disable RTC:
* Intel MID
* Lguest - uses paravirt
* Xen dom-U - uses paravirt
* x86 on legacy systems annotated with an ACPI legacy flag
We can consolidate all of these into a platform specific le
On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote:
There is already a check for apm_info.bios == 0, the
apm_info.bios is set from the boot_params.apm_bios_info.
Both Xen and lguest, which are also the only ones that set
paravirt_enabled to true, never set the apm_bios.info. The
Xen folks are sure
On 04/08/2016 02:29 AM, Luis R. Rodriguez wrote:
On Thu, Apr 7, 2016 at 10:18 PM, Juergen Gross wrote:
On 08/04/16 02:32, Luis R. Rodriguez wrote:
On Thu, Apr 07, 2016 at 08:55:54AM -0400, Boris Ostrovsky wrote:
On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote:
We have 4 types of x86
On 04/08/2016 03:59 AM, Juergen Gross wrote:
On 08/04/16 09:36, Luis R. Rodriguez wrote:
On Fri, Apr 8, 2016 at 12:13 AM, Juergen Gross wrote:
On 08/04/16 08:56, Luis R. Rodriguez wrote:
On Thu, Apr 7, 2016 at 11:38 PM, Juergen Gross wrote:
Okay. Another idea (not sure whether this is reall
On 04/08/2016 07:40 PM, Luis R. Rodriguez wrote:
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 1ae89a2721d6..8bb8c1a4615a 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -142,6 +142,15 @@ struct x86_cpuinit_ops {
struct
return value to zero when native_rdmsr_safe fails
With Xen (on top of eb1af3b):
Tested-by: Boris Ostrovsky
-boris
On 04/24/2016 04:23 PM, Borislav Petkov wrote:
On Mon, Feb 01, 2016 at 10:38:48AM -0500, Boris Ostrovsky wrote:
Start HVMlite guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
page, initialize boot_params, enable early page tables.
Since this stub is executed before kernel entry point
On 04/25/2016 09:47 AM, Borislav Petkov wrote:
On Mon, Apr 25, 2016 at 09:21:27AM -0400, Boris Ostrovsky wrote:
I was following Documentation/x86/boot.txt (plus comments in code preceding
those two routines) which I considered to be the API.
We are supposed to come to startup_32 with paging
On 04/25/2016 10:11 AM, Borislav Petkov wrote:
On Mon, Apr 25, 2016 at 09:54:37AM -0400, Boris Ostrovsky wrote:
Yes, those.
I don't think the ones in arch/x86/kernel/head_{32,64}.S are ABI.
Hmm... I thought that everything specified in boot.txt was ABI.
I don't think we c
On 04/25/2016 11:22 AM, Borislav Petkov wrote:
On Mon, Apr 25, 2016 at 10:42:15AM -0400, Boris Ostrovsky wrote:
Hmm... I thought that everything specified in boot.txt was ABI.
But those are not there.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/x86
On 03/29/2016 02:04 PM, Steven Haigh wrote:
Greg, please see below - this is probably more for you...
On 03/29/2016 04:56 AM, Steven Haigh wrote:
Interestingly enough, this just happened again - but on a different
virtual machine. I'm starting to wonder if this may have something to do
with the
On 04/04/2016 12:30 PM, David Vrabel wrote:
On 04/04/16 17:21, Julien Grall wrote:
(CC Stefano new e-mail address)
Hello Anna-Maria,
On 04/04/2016 13:32, Anna-Maria Gleixner wrote:
Xen guests do not offline/online CPUs during suspend/resume and
therefore FROZEN notifier transitions are not re
On 04/11/2016 10:08 PM, Stefano Stabellini wrote:
Hi all,
Unfortunately this patch (now commit
8c058b0b9c34d8c8d7912880956543769323e2d8) causes a regression on Xen
when running on top of QEMU: the number of PIT irqs get set to 0 by
probe_8259A but actually there are 16.
Any suggestions on how t
On 04/12/2016 02:06 PM, Stefano Stabellini wrote:
On Tue, 12 Apr 2016, Boris Ostrovsky wrote:
On 04/11/2016 10:08 PM, Stefano Stabellini wrote:
Hi all,
Unfortunately this patch (now commit
8c058b0b9c34d8c8d7912880956543769323e2d8) causes a regression on Xen
when running on top of QEMU: the
On 04/12/2016 05:14 PM, Stefano Stabellini wrote:
On Tue, 12 Apr 2016, Boris Ostrovsky wrote:
On 04/12/2016 02:06 PM, Stefano Stabellini wrote:
On Tue, 12 Apr 2016, Boris Ostrovsky wrote:
On 04/11/2016 10:08 PM, Stefano Stabellini wrote:
Hi all,
Unfortunately this patch (now commit
On 04/12/2016 05:56 PM, Stefano Stabellini wrote:
I am not sure, maybe you didn't have CONFIG_SPARSE_IRQ?
But I am certain that 4.6-rc2, with the attached config, fails as Dom0
on QEMU with the following sequence of calls:
I did have CONFIG_SPARSE_IRQ and I just rebuilt 4.5.0 with your con
On 04/12/2016 07:15 PM, Stefano Stabellini wrote:
On Tue, 12 Apr 2016, Boris Ostrovsky wrote:
On 04/12/2016 05:56 PM, Stefano Stabellini wrote:
I am not sure, maybe you didn't have CONFIG_SPARSE_IRQ?
But I am certain that 4.6-rc2, with the attached config, fails as Dom0
on QEMU wit
On 11/04/2015 03:02 PM, Sander Eikelenboom wrote:
On 2015-11-04 19:47, Stephen Smalley wrote:
On 11/04/2015 01:28 PM, Sander Eikelenboom wrote:
On 2015-11-04 16:52, Stephen Smalley wrote:
On 11/04/2015 06:55 AM, Sander Eikelenboom wrote:
Hi All,
I just tried to boot with the current linus me
On 11/05/2015 04:13 AM, Sander Eikelenboom wrote:
It makes "cat /sys/kernel/debug/kernel_page_tables" work and
prevents a kernel with CONFIG_DEBUG_WX=y from crashing at boot.
Great. Our nightly runs also failed spectacularly due to this bug.
It now does give a warning about an insecure W+X
X mappings") ptdump_walk_pgd_level_core() can now be called
during boot, causing a PV Xen guest to crash.
Reported-by: Sander Eikelenboom
Signed-off-by: Boris Ostrovsky
---
arch/x86/mm/dump_pagetables.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/dump_pagetables.
On 11/05/2015 05:31 PM, H. Peter Anvin wrote:
On 11/05/15 10:56, Boris Ostrovsky wrote:
The range between 0x8000 and 0x87ff is reserved
for hypervisor and therefore we should not try to follow PGD's indexes
corresponding to those addresses.
While this has alsways
On 11/20/2015 06:24 AM, Stefano Stabellini wrote:
On Wed, 18 Nov 2015, Boris Ostrovsky wrote:
After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
allocating descs for legacy IRQs") early_irq_init() will no longer
preallocate descriptors for legacy interrupts if PIC does
On 11/20/2015 10:36 AM, Stefano Stabellini wrote:
On Fri, 20 Nov 2015, Boris Ostrovsky wrote:
On 11/20/2015 06:24 AM, Stefano Stabellini wrote:
On Wed, 18 Nov 2015, Boris Ostrovsky wrote:
After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
allocating descs for legacy
escriptors ourselves.
Signed-off-by: Boris Ostrovsky
Suggested-by: Thomas Gleixner
---
v3: Add arm64 definition of nr_legacy_irqs()
arch/arm/include/asm/irq.h | 4
arch/arm64/include/asm/irq.h | 6 ++
drivers/xen/events/events_base.c | 5 +++--
3 files changed, 13 insertions(+), 2
On 11/20/2015 11:33 AM, Stefano Stabellini wrote:
BTW, I got this build error:
STUBCPY drivers/firmware/efi/libstub/lib-sort.stub.o
R_AARCH64_ABS64 __efistub_sort
0008 R_AARCH64_ABS64 .init__ksymtab_strings
drivers/firmware/efi/libstub/lib-sort.stub.o: abso
Export Xen symbols to dom0 via /proc/xen/xensyms (similar to
/proc/kallsyms).
Signed-off-by: Boris Ostrovsky
Reviewed-by: David Vrabel
---
drivers/xen/Kconfig | 8 +++
drivers/xen/xenfs/Makefile | 1 +
drivers/xen/xenfs/super.c| 3 +
drivers/xen/xenfs/xenfs.h
ches 1 and 4 have no changes
at all and patch 5 has minor changes due to rebasing so I kept David's
Reviewed-by tag.
Boris Ostrovsky (6):
xen: xensyms support
xen/PMU: Sysfs interface for setting Xen PMU mode
xen/PMU: Initialization code for Xen PMU
xen/PMU: Describe vendor-specifi
Add PMU emulation code that runs when we are processing a PMU interrupt.
This code will allow us not to trap to hypervisor on each MSR/LVTPC access
(of which there may be quite a few in the handler).
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/pmu.c | 214
Provide interfaces for recognizing accesses to PMU-related MSRs and
LVTPC APIC and process these accesses in Xen PMU code.
(The interrupt handler performs XENPMU_flush right away in the beginning
since no PMU emulation is available. It will be added with a later patch).
Signed-off-by: Boris
AMD and Intel PMU register initialization and helpers that determine
whether a register belongs to PMU.
This and some of subsequent PMU emulation code is somewhat similar to
Xen's PMU implementation.
Signed-off-by: Boris Ostrovsky
Reviewed-by: David Vrabel
---
arch/x86/xen/pmu.c
Set Xen's PMU mode via /sys/hypervisor/pmu/pmu_mode. Add XENPMU hypercall.
Signed-off-by: Boris Ostrovsky
---
Documentation/ABI/testing/sysfs-hypervisor-pmu | 23 +
arch/x86/include/asm/xen/hypercall.h | 6 ++
drivers/xen/sys-hypervisor.c
er patches.
Signed-off-by: Boris Ostrovsky
---
arch/x86/include/asm/xen/interface.h | 123 +
arch/x86/xen/Makefile| 2 +-
arch/x86/xen/apic.c | 3 +
arch/x86/xen/enlighten.c | 12 ++-
arch/x86/xen/pmu.c
On 07/02/2015 12:21 PM, David Vrabel wrote:
On 02/07/15 15:53, Boris Ostrovsky wrote:
Map shared data structure that will hold CPU registers, VPMU context,
V/PCPU IDs of the CPU interrupted by PMU interrupt. Hypervisor fills
this information in its handler and passes it to the guest for further
On 07/02/2015 12:25 PM, David Vrabel wrote:
On 02/07/15 15:53, Boris Ostrovsky wrote:
I haven't posted Linux part of PV(H) VPMU support in a while but now
that (hopefully) the hypervisor part is getting close to be done I
think it's time to post it again.
Remind me once the hyperviso
will overflow for a
domain configured with 8TB of memory or more.
Correct this by using the correct type.
Reviewed-by: Boris Ostrovsky
Signed-off-by: Juergen Gross
---
V2: change arm header as well to keep it in sync with x86
(requested by Julien Grall)
---
arch/arm/include/asm
On 09/17/2015 02:24 PM, Toshi Kani wrote:
Now that we have pud/pmd mask interfaces, which handle pfn & flags
mask properly for the large PAT bit.
Fix pud/pmd pfn & flags interfaces by replacing PTE_PFN_MASK and
PTE_FLAGS_MASK with the pud/pmd mask interfaces.
Suggested-by: Juergen Gross
Signed
On 11/09/2015 02:16 PM, Toshi Kani wrote:
On Mon, 2015-11-09 at 13:06 -0500, Boris Ostrovsky wrote:
On 09/17/2015 02:24 PM, Toshi Kani wrote:
Now that we have pud/pmd mask interfaces, which handle pfn & flags
mask properly for the large PAT bit.
Fix pud/pmd pfn & flags interfaces by r
On 11/09/2015 03:47 PM, Kirill A. Shutemov wrote:
On Mon, Nov 09, 2015 at 02:39:31PM -0500, Boris Ostrovsky wrote:
On 11/09/2015 02:16 PM, Toshi Kani wrote:
On Mon, 2015-11-09 at 13:06 -0500, Boris Ostrovsky wrote:
On 09/17/2015 02:24 PM, Toshi Kani wrote:
Now that we have pud/pmd mask
age's node (even if/when VNUMA is
implemented).
Marking grant maps' VMAs as VM_IO will exclude them from being
part of NUMA balancing.
Signed-off-by: Boris Ostrovsky
---
drivers/xen/gntdev.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/xen/gntdev.c b/
On 11/10/2015 02:36 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Nov 10, 2015 at 02:22:44PM -0500, Boris Ostrovsky wrote:
Doing so will cause the grant to be unmapped and then, during
fault handling, the fault to be mistakenly treated as NUMA hint
fault.
In addition, even if we those maps could
e (even if/when VNUMA is
implemented).
Marking grant maps' VMAs as VM_IO will exclude them from being
part of NUMA balancing.
Signed-off-by: Boris Ostrovsky
Cc: sta...@vger.kernel.org
---
- Added sta...@vger.kernel.org
drivers/xen/gntdev.c |2 +-
1 files changed, 1 insertions(+), 1 del
On 09/29/2015 07:39 AM, Vitaly Kuznetsov wrote:
Boris Ostrovsky writes:
On 09/25/2015 03:35 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 25, 2015 at 03:19:57PM -0400, Boris Ostrovsky wrote:
On 09/25/2015 03:01 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 25, 2015 at 01:17:40PM -0400, Boris
On 11/15/2015 01:02 PM, Andy Lutomirski wrote:
On Nov 13, 2015 5:23 PM, "Boris Ostrovsky" wrote:
On 11/13/2015 06:26 PM, Andy Lutomirski wrote:
On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
wrote:
After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
(&qu
On 11/16/2015 02:03 PM, Andy Lutomirski wrote:
It's still a waste of effort, though. Also, I'd eventually like the
number of places in Xen code in which rsp/esp is invalid to be exactly
zero, and this approach makes this harder or even impossible.
That's what PVH is going to do.
Does PVH h
On 11/16/2015 03:22 PM, Borislav Petkov wrote:
On Mon, Nov 16, 2015 at 12:11:11PM -0800, Andy Lutomirski wrote:
Are there really multiple feature bits for this stuff? I'd like to
imagine that the entry code is all either Xen PV or native/PVH/PVHVM
-- i.e. I assumed that PVH works like native f
On 11/03/2015 04:40 AM, Vitaly Kuznetsov wrote:
Commit d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain
interfaces") brought a regression for Hyper-V Gen2 instances. These
instances don't have i8259 legacy PIC but they use legacy IRQs for serial
port, rtc, and acpi. With this
On 11/16/2015 04:39 PM, Thomas Gleixner wrote:
On Mon, 16 Nov 2015, Boris Ostrovsky wrote:
Xen expects legacy interrupts to be there (pretty much for the same reason as
Hyper-V does) and with this change arch_probe_nr_irqs() returns zero and no
descriptors are allocated.
Right, because
On 11/17/2015 08:38 AM, Juergen Gross wrote:
Trying to boot a 4.4 kernel as Xen dom0 crashes the system:
[9.949589] ACPI: Added _OSI(Module Device)
[9.957803] ACPI: Added _OSI(Processor Device)
[9.966814] ACPI: Added _OSI(3.0 _SCP Extensions)
[9.976346] ACPI: Added _OSI(Processor
On 11/16/2015 04:55 PM, H. Peter Anvin wrote:
On 11/16/15 12:22, Borislav Petkov wrote:
Huh, so what's wrong with a jump:
jmp 1f
swapgs
1:
What is the point of that jump?
If it would make you feel better, it could be X86_BUG_XENPV :-p
That doesn't matter - I just do
After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
allocating descs for legacy IRQs") early_irq_init() will no longer
preallocate descriptors for legacy interrupts if PIT does not
exist.
Therefore we need to allocate those descriptors for PV guests
ourselves.
Signed-off
On 11/17/2015 02:16 PM, Andy Lutomirski wrote:
Looks good to me. Does Xen have any sysexit/sysret32 equivalent to
return to 32-bit user mode? If so, it could be worth trying to wire
it up by patching the jz instead of the test instruction.
We can actually make patching a little bit more effic
On 11/17/2015 02:37 PM, Boris Ostrovsky wrote:
On 11/17/2015 02:16 PM, Andy Lutomirski wrote:
Looks good to me. Does Xen have any sysexit/sysret32 equivalent to
return to 32-bit user mode? If so, it could be worth trying to wire
it up by patching the jz instead of the test instruction.
We
On 11/04/2015 01:47 PM, Stephen Smalley wrote:
On 11/04/2015 01:28 PM, Sander Eikelenboom wrote:
On 2015-11-04 16:52, Stephen Smalley wrote:
On 11/04/2015 06:55 AM, Sander Eikelenboom wrote:
Hi All,
I just tried to boot with the current linus mergewindow tree under
Xen.
It fails with a kern
On 9/6/19 8:27 AM, Souptick Joarder wrote:
> On Mon, Sep 2, 2019 at 2:04 PM Souptick Joarder wrote:
>> Rather than using static int max_dma_bits, this
>> can be coverted to use as macro.
>>
>> Signed-off-by: Souptick Joarder
>> Reviewed-by: Juergen Gross
> If it is still not late, can we get thi
On 9/3/19 8:20 PM, Igor Druzhinin wrote:
> If MCFG area is not reserved in E820, Xen by default will defer its usage
> until Dom0 registers it explicitly after ACPI parser recognizes it as
> a reserved resource in DSDT. Having it reserved in E820 is not
> mandatory according to "PCI Firmware Specif
On 9/6/19 7:00 PM, Igor Druzhinin wrote:
>
> On 06/09/2019 23:30, Boris Ostrovsky wrote:
>> On 9/3/19 8:20 PM, Igor Druzhinin wrote:
>>> If MCFG area is not reserved in E820, Xen by default will defer its usage
>>> until Dom0 registers it explicitly after ACPI
On 9/8/19 5:11 PM, Igor Druzhinin wrote:
> On 08/09/2019 19:28, Boris Ostrovsky wrote:
>> On 9/6/19 7:00 PM, Igor Druzhinin wrote:
>>> On 06/09/2019 23:30, Boris Ostrovsky wrote:
>>>> Where is MCFG parsed? pci_arch_init()?
>>>>> It happens twice:
>&g
On 9/8/19 7:37 PM, Igor Druzhinin wrote:
> On 09/09/2019 00:30, Boris Ostrovsky wrote:
>> On 9/8/19 5:11 PM, Igor Druzhinin wrote:
>>> On 08/09/2019 19:28, Boris Ostrovsky wrote:
>>>> On 9/6/19 7:00 PM, Igor Druzhinin wrote:
>>>>> On 06/09/2019 23:30
On 9/9/19 5:48 PM, Igor Druzhinin wrote:
> On 09/09/2019 20:19, Boris Ostrovsky wrote:
>> On 9/8/19 7:37 PM, Igor Druzhinin wrote:
>>> On 09/09/2019 00:30, Boris Ostrovsky wrote:
>>>> On 9/8/19 5:11 PM, Igor Druzhinin wrote:
>>>>> On 08/09/2019 19:28,
On Mon, Aug 26, 2019 at 01:32:48PM -0700, Raj, Ashok wrote:
> On Mon, Aug 26, 2019 at 08:53:05AM -0400, Boris Ostrovsky wrote:
> > On 8/24/19 4:53 AM, Borislav Petkov wrote:
> > >
> > > +wait_for_siblings:
> > > + if (__wait_for_cpus(&late_cpus_out, NSEC_
701 - 800 of 1678 matches
Mail list logo
