On 04/10/2013 08:30 PM, tip-bot for Boris Ostrovsky wrote:
Commit-ID: 511ba86e1d386f671084b5d0e6f110bb30b8eeb2
Gitweb: http://git.kernel.org/tip/511ba86e1d386f671084b5d0e6f110bb30b8eeb2
Author: Boris Ostrovsky boris.ostrov...@oracle.com
AuthorDate: Sat, 23 Mar 2013 09:36:36 -0400
in __tlb_remove_page() - tlb_next_batch().
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/mm/pageattr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 091934e..2ccbe0b 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86
On 03/23/2013 09:36 AM, Konrad Rzeszutek Wilk wrote:
From: Boris Ostrovsky boris.ostrov...@oracle.com
Invoking arch_flush_lazy_mmu_mode() results in calls to
preempt_enable()/disable() which may have performance impact.
Since lazy MMU is not used on bare metal we can patch away
use.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c
b/arch/x86/kernel/cpu/mcheck/mce_amd.c
index 1ac581f..cb7c739
Use helper function instead of an array to report whether register
bank is shared. Currently only bank 4 (northbridge) is shared.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 17 +
1 file changed, 9 insertions(+), 8
Boris,
Here is the updated patch for determining number of regiter banks on
AMD plus a patch removing shared_bank array, as you suggested.
Offline/online testing didn't show any issues.
Boris Ostrovsky (2):
x86/mce: Replace shared_bank array with is_shared_bank() helper
x86/mce: Use
should use.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c
b/arch/x86/kernel/cpu/mcheck/mce_amd.c
index 654a155
- jwbo...@redhat.com wrote:
On Wed, Mar 13, 2013 at 09:25:44AM -0400, Boris Ostrovsky wrote:
On 03/01/2013 07:14 AM, Josh Boyer wrote:
On Thu, Feb 28, 2013 at 04:52:20PM -0800, H. Peter Anvin wrote:
On 02/28/2013 04:42 PM, Josh Boyer wrote:
On Fri, Mar 01, 2013 at 01:36:29AM +0100
On 03/01/2013 07:14 AM, Josh Boyer wrote:
On Thu, Feb 28, 2013 at 04:52:20PM -0800, H. Peter Anvin wrote:
On 02/28/2013 04:42 PM, Josh Boyer wrote:
On Fri, Mar 01, 2013 at 01:36:29AM +0100, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 04:15:45PM -0800, H. Peter Anvin wrote:
I'll try to get
Add family 16h PCI ID to AMD's power driver to allow it report
power consumption on these processors.
Signed-off-by: Boris Ostrovsky boris.ostrov...@amd.com
---
drivers/hwmon/fam15h_power.c |1 +
include/linux/pci_ids.h |1 +
2 files changed, 2 insertions(+)
diff --git a/drivers
Add family 16h PCI ID to AMD's power driver to allow it report
power consumption on these processors.
Signed-off-by: Boris Ostrovsky boris.ostrov...@amd.com
---
drivers/hwmon/fam15h_power.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon
From: Boris Ostrovsky boris.ostrov...@amd.com
Enable WC+ memory type on AMD family 10h processors if BIOS doesn't do
this. WC+ is used only in in virtualized scenarios and never in bare metal
cases (see AMD APM v2).
Also clean up init_amd() a little.
Boris Ostrovsky (2):
AMD,x86: Clean up
From: Boris Ostrovsky boris.ostrov...@amd.com
Clean up multiple declarations of variable used for rd/wrmsr
Signed-off-by: Boris Ostrovsky boris.ostrov...@amd.com
---
arch/x86/kernel/cpu/amd.c | 29 -
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git
From: Boris Ostrovsky boris.ostrov...@amd.com
In some cases BIOS may not enable WC+ memory type on family 10
processors, instead converting what would be WC+ memory to CD type.
On guests using nested pages this could result in performance
degradation. This patch enables WC+.
Signed-off-by: Boris
up init_amd() a little.
Boris Ostrovsky (2):
AMD,x86: Clean up init_amd()
x86,AMD: Enable WC+ memory type on family 10 processors
arch/x86/include/uapi/asm/msr-index.h |1 +
arch/x86/kernel/cpu/amd.c | 49 ++---
2 files changed, 28 insertions
Clean up multiple declarations of variable used for rd/wrmsr
Signed-off-by: Boris Ostrovsky boris.ostrov...@amd.com
---
arch/x86/kernel/cpu/amd.c | 29 -
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu
In some cases BIOS may not enable WC+ memory type on family 10
processors, instead converting what would be WC+ memory to CD type.
On guests using nested pages this could result in performance
degradation. This patch enables WC+.
Signed-off-by: Boris Ostrovsky boris.ostrov...@amd.com
---
arch
in __tlb_remove_page() - tlb_next_batch().
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/mm/pageattr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index ca1f1c2..7b3216e 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86
- h...@zytor.com wrote:
On 02/26/2013 02:56 PM, Boris Ostrovsky wrote:
When CONFIG_DEBUG_PAGEALLOC is set page table updates made by
kernel_map_pages() are not made visible (via TLB flush) immediately
if lazy
MMU is on. In environments that support lazy MMU (e.g. Xen) this may
lead
On 02/28/2013 11:10 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the **COMMON!**
case that we are not on a PV platform.
... or, patch it out with the alternatives on baremetal, as Steven
On 02/28/2013 11:22 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
On 02/28/2013 11:10 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the **COMMON
Invoking arch_flush_lazy_mmu_mode() results in calls to
preempt_enable()/disable() which may have performance impact.
Since lazy MMU is not used on bare metal we can patch away
arch_flush_lazy_mmu_mode() so that it is never called in such
environment.
Signed-off-by: Boris Ostrovsky boris.ostrov
On 01/20/2013 06:57 AM, Jörg Rödel wrote:
On Sun, Jan 20, 2013 at 12:48:28PM +0100, Borislav Petkov wrote:
On Sun, Jan 20, 2013 at 12:40:11PM +0100, Jörg Rödel wrote:
Yes, the BIOS vendor can fix this issue. They need to disable NB clock
gating for the IOMMU.
Right, Udo, you can try
On 01/18/2013 02:00 PM, Konrad Rzeszutek Wilk wrote:
So something like this in the hypervisor maybe (not even tested):
diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c
b/xen/arch/x86/acpi/cpufreq/powernow.c
index a9b7792..54e7808 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++
On 01/22/2013 09:13 AM, Udo van den Heuvel wrote:
Gigabyte demonstrate that using ESX 5i IOMMU works fine. (with pictures
attached).
There are no attachments to your message.
I am not sure that 5i supports IOMMU (but I may well be wrong).
What can we bring against that?
How
On 01/22/2013 10:27 AM, Udo van den Heuvel wrote:
On 2013-01-22 15:36, Boris Ostrovsky wrote:
Gigabyte demonstrate that using ESX 5i IOMMU works fine. (with pictures
attached).
There are no attachments to your message.
Correct, gigabyte did send them via their support web-interface.
Do yo
On 01/18/2013 02:00 PM, Konrad Rzeszutek Wilk wrote:
Right, that information is gathered from the MSRs. I think the Xen would
need to do this since it can do the MSRs correctly and modify the P-states.
So something like this in the hypervisor maybe (not even tested):
Is there any harm in
On 02/19/2013 12:57 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Feb 19, 2013 at 06:47:58PM +0100, Borislav Petkov wrote:
On Tue, Feb 19, 2013 at 09:38:31AM -0800, H. Peter Anvin wrote:
My fault... I was tracking the fix and lost track of the thread.
The problem is that the fix is necessary but
On 02/19/2013 01:21 PM, H. Peter Anvin wrote:
On 02/19/2013 10:19 AM, Boris Ostrovsky wrote:
On 02/19/2013 12:57 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Feb 19, 2013 at 06:47:58PM +0100, Borislav Petkov wrote:
On Tue, Feb 19, 2013 at 09:38:31AM -0800, H. Peter Anvin wrote:
My fault... I
Add valid patch size for family 16h processors
Signed-off-by: Boris Ostrovsky boris.ostrov...@amd.com
---
arch/x86/kernel/microcode_amd.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c
index 7720ff5..58790e8 100644
On 11/15/2012 03:45 PM, Henrique de Moraes Holschuh wrote:
On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
Add valid patch size for family 16h processors
Signed-off-by: Boris Ostrovsky boris.ostrov...@amd.com
Is this something that needs to go to -stable ?
#define F1XH_MPB_MAX_SIZE 2048
On 11/15/2012 06:01 PM, Gene Heskett wrote:
On Thursday 15 November 2012, Henrique de Moraes Holschuh wrote:
On Thu, 15 Nov 2012, Boris Ostrovsky wrote:
Add valid patch size for family 16h processors
Signed-off-by: Boris Ostrovsky boris.ostrov...@amd.com
Is this something that needs to go
On 08/05/2013 02:05 PM, Konrad Rzeszutek Wilk wrote:
Both Boris and David have graciously volunteered to help in
maintaining the Xen subsystem tree. Cementing this in the
MAINTAINERS file so they are copied on Xen related patches.
CC: Boris Ostrovsky boris.ostrov...@oracle.com
CC: David Vrabel
Set Xen's PMU mode via /sys/hypervisor/pmu/pmu_mode. Add XENPMU hypercall.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/include/asm/xen/hypercall.h | 6 ++
arch/x86/xen/xen-head.S | 5 +-
drivers/xen/sys-hypervisor.c | 118
to
/proc/kallsyms)
* VPMU infrastructure is now used for both HVM and PV and therefore has been
moved
up from hvm subtree
Boris Ostrovsky (5):
xen: xensyms support
xen/PMU: Sysfs interface for setting Xen PMU mode
xen/PMU: Initialization code for Xen PMU
xen/PMU: Add support for PMU
Export Xen symbols to dom0 via /proc/xen/xensyms (similar to /proc/kallsyms).
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
drivers/xen/Kconfig | 5 ++
drivers/xen/xenfs/Makefile | 1 +
drivers/xen/xenfs/super.c| 3 +
drivers/xen/xenfs/xenfs.h
Avoid trapping to hypervisor on each MSR access during interrupt handling.
Instead, use cached MSR values provided in shared xenpmu_data by Xen. When
handling is completed, flush the registers to hypervisor who will load them
into HW.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Map shared data structure that will hold CPU registers, VPMU context,
VCPU/PCPI IDs of the VCPU interrupted by PMU interrupt. Hypervisor
fills this information in its handler and passes it to the guest for
further processing.
Set up PMU VIRQ.
Signed-off-by: Boris Ostrovsky boris.ostrov
PMU emulation code: MSR caching in PMU context and LVTPC APIC
handling. (Portions of this code are taken from Xen's VPMU
implementation)
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/xen/enlighten.c | 27 +++-
arch/x86/xen/pmu.c | 289
On 09/11/2013 05:33 AM, David Vrabel wrote:
On 10/09/13 16:31, Boris Ostrovsky wrote:
This is the Linux side of Xen PMU support for PV guests, including dom0. Only
kernel changes are here, toolstack patch will be provided separately.
Here is description from the hypervisor patch submission
() runs.)
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/xen/spinlock.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 253f63f
down extra pages, decreasing amount of
available memory for no good reason.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
drivers/xen/balloon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index b232908..1b62304
- torva...@linux-foundation.org wrote:
On Sun, Oct 6, 2013 at 1:23 AM, Fengguang Wu fengguang...@intel.com
wrote:
I got the below dmesg and the first bad commit is commit
cf39c8e5352b:
Merge tag 'stable/for-linus-3.12-rc0-tag' of
://bugs.xenproject.org/xen/bug/6
Reported-by: Alex Bligh a...@alex.org.uk
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
[v2: Add switch statement]
Reviewed-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
drivers/xen/manage.c | 13 -
1 file changed, 12 insertions
of this variable. Surfacing the 'xenwatch_mutex'
out of XenBus is not a nice way of doing it. Having the
variable however be atomic solves the problem easily.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
[v2: Don't expose xenwatch_mutex, add comments]
Reviewed-by: Boris Ostrovsky boris.ostrov
Tony, Fenghua,
We had a discussion at the last Xen Summit about status of Linux' IA64
Xen. Xen itself dropped IA64 support in 4.2 (it is approaching 4.4 now)
and it's not clear whether we can even build Linux/Xen/IA64 against
latest Xen sources, let alone run it.
The proposal at the summit
On 03/03/2014 09:40 PM, Boris Ostrovsky wrote:
Xen PV guests support only few APIC registers and writes to
unsupported registers result in WARN_ONs. Most APIC accesses in these
guests have been eliminated; however, lapic_suspend/resume are still
called (on 32-bit kernels).
We can disable APIC
On 02/26/2014 11:24 AM, Roger Pau Monne wrote:
Add support for MSI message groups for Xen Dom0 using the
MAP_PIRQ_TYPE_MULTI_MSI pirq map type.
In order to keep track of which pirq is the first one in the group all
pirqs in the MSI group except for the first one have the newly
introduced
On 02/27/2014 10:45 AM, Roger Pau Monné wrote:
@@ -291,7 +290,10 @@ static int xen_initdom_setup_msi_irqs(struct
pci_dev *dev, int nvec, int type)
(pci_domain_nr(dev-bus) 16);
map_irq.devfn = dev-devfn;
-if (type == PCI_CAP_ID_MSIX) {
+if
PIRQ_MSI_GROUP flag set. This prevents calling
PHYSDEVOP_unmap_pirq on them, since the unmap must be done with the
first pirq in the group.
Reviewed-by: Boris Ostrovsky boris.ostrov...@oracle.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On 02/27/2014 01:45 PM, Boris Ostrovsky wrote:
On 02/27/2014 01:15 PM, Roger Pau Monne wrote:
Add support for MSI message groups for Xen Dom0 using the
MAP_PIRQ_TYPE_MULTI_MSI pirq map type.
In order to keep track of which pirq is the first one in the group all
pirqs in the MSI group except
On 02/28/2014 12:46 PM, Roger Pau Monné wrote:
On 28/02/14 18:20, Boris Ostrovsky wrote:
On 02/27/2014 01:45 PM, Boris Ostrovsky wrote:
On 02/27/2014 01:15 PM, Roger Pau Monne wrote:
Add support for MSI message groups for Xen Dom0 using the
MAP_PIRQ_TYPE_MULTI_MSI pirq map type.
In order
On 02/28/2014 01:10 PM, Roger Pau Monné wrote:
On 28/02/14 19:00, Boris Ostrovsky wrote:
On 02/28/2014 12:46 PM, Roger Pau Monné wrote:
On 28/02/14 18:20, Boris Ostrovsky wrote:
On 02/27/2014 01:45 PM, Boris Ostrovsky wrote:
On 02/27/2014 01:15 PM, Roger Pau Monne wrote:
Add support for MSI
()
(which is called after APIC has been initialized).
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/include/asm/apic.h |2 ++
arch/x86/kernel/apic/apic.c |6 ++
arch/x86/xen/smp.c |4
3 files changed, 12 insertions(+)
An alternative could
On 03/04/2014 05:25 AM, David Vrabel wrote:
On 04/03/14 02:40, Boris Ostrovsky wrote:
Xen PV guests support only few APIC registers and writes to
unsupported registers result in WARN_ONs. Most APIC accesses in these
guests have been eliminated; however, lapic_suspend/resume are still
called
On 01/10/2014 11:28 AM, Olaf Hering wrote:
In its initial implementation a check for type was added, but only phy
and file are handled. This breaks advertised discard support for other
type values such as qdisk.
Fix and simplify this function: If the backend advertises discard
support it is
On 01/10/2014 04:37 PM, Olaf Hering wrote:
On Fri, Jan 10, Boris Ostrovsky wrote:
If the call below fails, is it safe to continue using discard feature? At
the least, are discard_granularity and discard_alignment guaranteed to have
sane/safe values?
Its up to the toolstack to provide sane
On 01/10/2014 05:49 PM, Olaf Hering wrote:
On Fri, Jan 10, Boris Ostrovsky wrote:
I think we should at clear feature_discard and print an error in the log if
*either* of xenbus_gather() calls fail.
Are you sure about that? AFAIK many other properties are optional as
well. I dont think
On 01/13/2014 04:30 AM, Olaf Hering wrote:
On Fri, Jan 10, Boris Ostrovsky wrote:
I don't know discard code works but it seems to me that if you pass, for
example, zero as discard_granularity (which may happen if xenbus_gather()
fails) then blkdev_issue_discard() in the backend will set
On 01/13/2014 06:07 PM, Olaf Hering wrote:
On Mon, Jan 13, Boris Ostrovsky wrote:
On 01/13/2014 04:30 AM, Olaf Hering wrote:
Similarly, if xenbug_gather(discard-secure) fails, I think the code will
assume that secure discard has not been requested. I don't know what
security implications
konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
Cc: Ingo Molnar mi...@kernel.org
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
drivers/xen/balloon.c | 35
num_present_cpus().
Reported-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
kernel/sched/cpudeadline.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index
On 02/15/2014 11:51 AM, Srivatsa S. Bhat wrote:
On 02/14/2014 10:20 PM, Srivatsa S. Bhat wrote:
On 02/14/2014 10:19 PM, Boris Ostrovsky wrote:
On 02/14/2014 02:59 AM, Srivatsa S. Bhat wrote:
Subsystems that want to register CPU hotplug callbacks, as well as
perform
initialization for the CPUs
-off-by: Alexander Gordeev agord...@redhat.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
Cc: linux-...@vger.kernel.org
---
drivers/xen/xen-pciback/pciback_ops.c | 16 ++--
1 files changed
On 02/19/2014 10:22 AM, Boris Ostrovsky wrote:
On 02/19/2014 05:15 AM, Alexander Gordeev wrote:
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range
On 02/19/2014 11:05 AM, Alexander Gordeev wrote:
On Wed, Feb 19, 2014 at 10:40:19AM -0500, Boris Ostrovsky wrote:
diff --git a/drivers/xen/xen-pciback/pciback_ops.c
b/drivers/xen/xen-pciback/pciback_ops.c
index 64eb0cd..f5b4c3e 100644
--- a/drivers/xen/xen-pciback/pciback_ops.c
+++ b/drivers
()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
Cc: linux-...@vger.kernel.org
Reviewed-by: Boris Ostrovsky
On 02/21/2014 01:58 PM, Alexander Gordeev wrote:
On Fri, Feb 21, 2014 at 01:33:34PM -0500, Boris Ostrovsky wrote:
Reviewed-by: Boris Ostrovsky boris.ostrov...@oracle.com
Thank you, Boris!
Whom should I ask this patch for inclusion?
This should go into the Xen tree. Konrad is usually the one
On 02/08/2014 05:35 PM, Paul Bolle wrote:
Commit d52eefb47d4e (ia64/xen: Remove Xen support for ia64) removed
the Kconfig symbol XEN_XENCOMM. But it didn't remove the code depending
on that symbol. Remove that code now.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Basically only tested with
On 10/07/2013 02:55 AM, Greg Kroah-Hartman wrote:
The dev_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the xenbus code to use the
correct field.
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov
, there
is no put_balloon_scratch_page() in the error path.)
In addition, the second multicall uses __xen_mc_entry() which does not disable
interrupts. Rearrange xen_mc_* calls to keep interrupts off while performing
multicalls.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/xen/p2m.c
- michael.opdenac...@free-electrons.com wrote:
This patch proposes to remove the IRQF_DISABLED flag from x86/xen
code. It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
michael.opdenac...@free-electrons.com
---
arch/x86/xen/smp.c | 10
On 09/23/2013 09:17 AM, Konrad Rzeszutek Wilk wrote:
On Tue, Sep 10, 2013 at 11:31:47AM -0400, Boris Ostrovsky wrote:
+
+/* Parameter structure for HYPERVISOR_xenpmu_op call */
+struct xenpmu_params {
+ union {
+ struct version {
+ uint8_t maj
On 09/23/2013 09:26 AM, Konrad Rzeszutek Wilk wrote:
On Tue, Sep 10, 2013 at 11:31:48AM -0400, Boris Ostrovsky wrote:
Map shared data structure that will hold CPU registers, VPMU context,
VCPU/PCPI IDs of the VCPU interrupted by PMU interrupt. Hypervisor
fills this information in its handler
On 09/23/2013 10:18 AM, Boris Ostrovsky wrote:
On 09/23/2013 09:26 AM, Konrad Rzeszutek Wilk wrote:
On Tue, Sep 10, 2013 at 11:31:48AM -0400, Boris Ostrovsky wrote:
Map shared data structure that will hold CPU registers, VPMU context,
VCPU/PCPI IDs of the VCPU interrupted by PMU interrupt
On 09/12/2013 10:47 PM, Steven Rostedt wrote:
On Thu, 12 Sep 2013 22:29:44 -0400
Boris Ostrovsky boris.ostrov...@oracle.com wrote:
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
xen_init_spinlocks() currently calls static_key_slow_inc() before
jump_label_init() is invoked. When
-wall_to_monotonic.tv_nsec tk-shift)
So if, for example, tv_nsec is 0x80 and shift is 8 we will end up
with 0x8000 instead of 0x8000. And then we are stuck in
the subsequent 'while' loop.
We need explicit cast.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Konrad
On 05/09/2014 11:43 AM, H. Peter Anvin wrote:
On 05/09/2014 08:11 AM, Boris Ostrovsky wrote:
With tk-wall_to_monotonic.tv_nsec being a 32-bit value on 32-bit
systems, (tk-wall_to_monotonic.tv_nsec tk-shift) in update_vsyscall()
may lose upper bits or, worse, add them since compiler will do
On 05/09/2014 12:03 PM, H. Peter Anvin wrote:
On 05/09/2014 08:59 AM, Boris Ostrovsky wrote:
On 05/09/2014 11:43 AM, H. Peter Anvin wrote:
On 05/09/2014 08:11 AM, Boris Ostrovsky wrote:
With tk-wall_to_monotonic.tv_nsec being a 32-bit value on 32-bit
systems, (tk-wall_to_monotonic.tv_nsec tk
On 06/13/2014 08:45 AM, Konrad Rzeszutek Wilk wrote:
On Fri, Jun 13, 2014 at 01:26:28PM +0200, Vitaly Kuznetsov wrote:
some old Xen hypervisors (prior to 3.2) forbid DomUs to register
NMI callbacks. E.g. we have the following code in xen-3.1:
if ( (d-domain_id != 0) || (v-vcpu_id != 0) )
it was
in the original patch.
In other words, the whole fix would be moving !container check up.
(64-bit relocation is a separate issue).
No?
-boris
Also, take care of the ramdisk relocation on both bitness.
Reported-by: Boris Ostrovsky boris.ostrov...@oracle.com
Signed-off-by: Borislav Petkov b...@suse.de
On 02/03/2014 02:30 PM, Borislav Petkov wrote:
On Mon, Feb 03, 2014 at 02:13:27PM -0500, Boris Ostrovsky wrote:
I thought that it may be sufficient to check for !container in
save_microcode_in_initrd_amd() before performing relocation. If the
signature was wrong, we would have found out about
On 02/03/2014 02:52 PM, Borislav Petkov wrote:
On Mon, Feb 03, 2014 at 02:37:34PM -0500, Boris Ostrovsky wrote:
It exploded when 'if (!container)' check was done *after* relocation,
which made container non-zero. If you do the check *before* then I
think you will catch the fact that container
On 01/21/2014 01:25 PM, Borislav Petkov wrote:
On Tue, Jan 21, 2014 at 12:55:53PM -0500, Boris Ostrovsky wrote:
cat $(AMD_UCODE_PATH)/*
ucode_initrd/kernel/x86/microcode/AuthenticAMD.bin
(cd ucode_initrd;find . | cpio -o -H newc
../$(DISTDIR)/common/ucode_initrd.cpio
On 01/23/2014 01:54 PM, Gene Heskett wrote:
On Thursday 23 January 2014, Boris Ostrovsky wrote:
On 01/21/2014 01:25 PM, Borislav Petkov wrote:
On Tue, Jan 21, 2014 at 12:55:53PM -0500, Boris Ostrovsky wrote:
cat $(AMD_UCODE_PATH)/*
ucode_initrd/kernel/x86/microcode
On 01/23/2014 02:29 PM, Borislav Petkov wrote:
On Thu, Jan 23, 2014 at 01:08:46PM -0500, Boris Ostrovsky wrote:
So I tried this on a good system and I am pretty sure this is
broken. I don't have any microcode in initrd and I am still dying in
load_microcode_amd().
32-bit still or 64-bit?
32
On 01/28/2014 02:38 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Jan 28, 2014 at 06:43:32PM +0100, Roger Pau Monne wrote:
blkback bug fixes for memory leaks (patches 1 and 2) and a race
(patch 3).
They all look OK to me. I've stuck them in my 'stable/for-jens-3.14'
branch and are testing them now
On 01/28/2014 11:24 AM, Borislav Petkov wrote:
On Thu, Jan 23, 2014 at 02:41:59PM -0500, Boris Ostrovsky wrote:
32-bit only.
Ok, I think I know what happens. Can you try this one (I missed doing
this on 32-bit and 64-bit does it, which would explain why it didn't
explode there):
---
diff
On 01/28/2014 03:52 PM, Borislav Petkov wrote:
On Tue, Jan 28, 2014 at 03:43:57PM -0500, Boris Ostrovsky wrote:
It fixes the case when there is no microcode in initrd but when
microcode is corrupted (as was the case when we were pointing to Intel
binary) we still die. Neither container nor
On 01/28/2014 04:30 PM, Borislav Petkov wrote:
On Tue, Jan 28, 2014 at 04:05:20PM -0500, Boris Ostrovsky wrote:
Yes. This was a bug in our build environment. It is fixed now but I
put this bug back when I was testing your patch.
Right, that was the deal. Oh well, we'd need to verify
On 01/28/2014 04:37 PM, Boris Ostrovsky wrote:
On 01/28/2014 04:30 PM, Borislav Petkov wrote:
On Tue, Jan 28, 2014 at 04:05:20PM -0500, Boris Ostrovsky wrote:
Yes. This was a bug in our build environment. It is fixed now but I
put this bug back when I was testing your patch.
Right
On 01/30/2014 10:13 AM, Borislav Petkov wrote:
On Wed, Jan 29, 2014 at 12:22:19AM +0100, Borislav Petkov wrote:
Are you sure that
container = (u8 *)(__va((u32)relocated_ramdisk) +
((u32)container -
boot_params.hdr.ramdisk_image));
in
On 12/12/2013 09:10 PM, Konrad Rzeszutek Wilk wrote:
From: Mukesh Rathor mukesh.rat...@oracle.com
.. which are surprinsingly small compared to the amount for PV.
First the set/clear mmio pte function make a hypercall to update the
P2M in Xen with 1:1 mapping. Since PVH uses mostly native mmu
On 12/12/2013 09:10 PM, Konrad Rzeszutek Wilk wrote:
From: Mukesh Rathor mukesh.rat...@oracle.com
In the bootup code for PVH we can trap cpuid via vmexit, so don't
need to use emulated prefix call. We also check for vector callback
early on, as it is a required feature. PVH also runs at default
Steven,
Looks like commit 198d208df (x86: Keep thread_info on thread stack in
x86_32) broke Xen's 32-bit PV guests.
I poked a little at it and it seems that at least the ifdef in
xen_cpu_up() needs to be adjusted to set up kernel_stack --- that allows
CPUs to get going. This is not enough
On 04/03/2014 11:23 PM, Boris Ostrovsky wrote:
Steven,
Looks like commit 198d208df (x86: Keep thread_info on thread stack in
x86_32) broke Xen's 32-bit PV guests.
I poked a little at it and it seems that at least the ifdef in
xen_cpu_up() needs to be adjusted to set up kernel_stack
. If it is an initial domain and hurtling towards
death - there is no point of continuing the wait. All other type
of guests continue with their behavior.
mechanism a bit more asynchronous.
This looks like a runaway sentence.
Other than that
Reviewed-by: Boris Ostrovsky boris.ostrov...@oracle.com
not be the kernel's
version when executing xen_iret()
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/xen/smp.c|3 ++-
arch/x86/xen/xen-asm_32.S |4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index
On 04/09/2014 11:01 AM, Jan Beulich wrote:
On 09.04.14 at 16:41, andrew.coop...@citrix.com wrote:
The latter load however can easy fault; The arguments for %ds in
XSA-42/ CVE-2013-0228 applies to %{e,f,g}s as well.
And it was only that latter operation that I pointed at.
We don't seem to
On 04/09/2014 11:25 AM, Steven Rostedt wrote:
On Wed, 09 Apr 2014 11:12:33 -0400
Boris Ostrovsky boris.ostrov...@oracle.com wrote:
Commit 198d208df4371734ac4728f69cb585c284d20a15 made 32-bit kernels use
kernel_stack to point to thread_info. That change missed a couple of
updates needed
1 - 100 of 3117 matches
Mail list logo
