On 10.11.14 at 11:51, dario.faggi...@citrix.com wrote:
I'm 100% ok to re-start that discussion here and now... however, how
stable should this interface be? Can't we deal with this when actually
implementing NUMA aware ballooning and add stuff at than point, if
necessary?
Wei's desire to
On 12.11.14 at 07:58, robert...@intel.com wrote:
2. Failed to hotplug a VT-d device with XEN4.5-RC1
http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894
First of all I'm not sure it is really useful to use the old, discontinued
bugzilla to report bugs. I think it would be
On 12.11.14 at 10:13, tiejun.c...@intel.com wrote:
On 2014/11/12 17:02, Jan Beulich wrote:
On 12.11.14 at 09:45, tiejun.c...@intel.com wrote:
#2 flags field in each specific device of new domctl would control
whether this device need to check/reserve its own RMRR range. But its
not dependent
On 12.11.14 at 11:46, andrew.coop...@citrix.com wrote:
On 12/11/14 10:40, Juergen Gross wrote:
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -225,6 +225,35 @@ static int cpupool_destroy(struct cpupool *c)
}
/*
+ * Move domain to another cpupool
+ */
+static int
On 12.11.14 at 14:45, wei.l...@citrix.com wrote:
On Wed, Nov 12, 2014 at 09:35:01AM +, Jan Beulich wrote:
On 11.11.14 at 19:03, david.vra...@citrix.com wrote:
On 11/11/14 17:36, Wei Liu wrote:
Option #1 requires less modification to guest, because guest won't
need to switch to new
On 12.11.14 at 15:40, wei.l...@citrix.com wrote:
So what's the usual technique in Linux to make sure if a specific
Xen feature is present?
Jan, is it suitable to use a XENFEAT_* bit for this?
Yes, that would be the canonical way.
Jan
___
On 12.11.14 at 16:25, david.vra...@citrix.com wrote:
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+ u64 max_mfn;
+
+ max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
+
+ return DMA_BIT_MASK(fls64(max_mfn PAGE_SHIFT) + 1);
+}
The value the
On 13.11.14 at 06:31, liang.z...@intel.com wrote:
Apart from the subject being kind of wrong (you're not turning it on
by default, but only expose it if the hardware supports it), ...
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -192,6 +192,7 @@ static void
On 13.11.14 at 03:32, robert...@intel.com wrote:
Hi,
This is a separated report for bug
http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897
Environment:
Service Arch (ia32/ia32e/IA64): ia32e
Guest Arch (ia32/ia32e/IA64):
Guest OS Type (Linux/Windows):
On 13.11.14 at 00:52, am...@gatech.edu wrote:
Hello,
I am trying to set up a shared page between the hypervisor and a Linux guest
kernel. In Xen I am doing:
void *ptr = alloc_xenheap_page();
share_xen_page_with_guest(virt_to_page(ptr), current-domain,
XENSHARE_writable);
unsigned int
All,
while the 3 month period since the previous stable releases would
expire at the beginning of December, looking at the number of
changes in the stable trees I don't think starting preparations right
now would make much sense. Unless I hear severe objections to
this plan, and unless 4.5 gets
On 13.11.14 at 11:25, jbeul...@suse.com wrote:
On 12.11.14 at 16:25, david.vra...@citrix.com wrote:
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -13,4 +13,6 @@ struct dev_archdata {
struct pdev_archdata {
};
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
Is
-by: Jan Beulich jbeul...@suse.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
as the 1st one deleted them all,
- a chosen node should be found as it got added in the 1st pass,
- the various linux,uefi-* nodes all got added during the 1st pass
and hence only their contents may get updated.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/efi/efi-boot.h
+++ b
On 14.11.14 at 14:11, li...@eikelenboom.it wrote:
(XEN) [2014-11-14 13:00:06.810] [ Xen-4.5.0-rc x86_64 debug=y Not
tainted ]
(XEN) [2014-11-14 13:00:06.810] CPU:3
(XEN) [2014-11-14 13:00:06.810] RIP:e008:[82d080148f14]
dpci_softirq+0x9c/0x231
(XEN) [2014-11-14
On 14.11.14 at 16:20, li...@eikelenboom.it wrote:
If it still helps i could try Andrews suggestion and try out with only
commit aeeea485 ..
Yes, even if it's pretty certain it's the second of the commits, verifying
this would be helpful (or if the assumption is wrong, the pattern it's
dying
On 17.11.14 at 08:57, tiejun.c...@intel.com wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -698,10 +698,13 @@ struct get_reserved_device_memory {
unsigned int used_entries;
};
-static int get_reserved_device_memory(xen_pfn_t start,
-
On 14.11.14 at 16:32, konrad.w...@oracle.com wrote:
On Fri, Nov 14, 2014 at 12:37:30PM +, Jan Beulich wrote:
The specification is kind of vague under what conditions
ExitBootServices() may legitimately fail, requiring the OS loader to
retry:
If MapKey value is incorrect
On 17.11.14 at 14:32, donald.d.dug...@intel.com wrote:
Hmm, good ideas. How about I change the `snb_igd_quirk' parameter to be:
snb_igd_quirk = current behavior, enable
quirk with 1 sec timeout
snb_igd_quirk=default = enable quirk with
On 17.11.14 at 15:51, donald.d.dug...@intel.com wrote:
My primary goal is to decouple the IGD quirk code from the VTd timeout value,
the two are unrelated and shouldn't be using the same define. In the process
we can clean up the IGD code so that, if a user wants, the user can specify a
On 17.11.14 at 16:39, ian.jack...@eu.citrix.com wrote:
Liang Li writes ([PATCH] libxc: Expose the pdpe1gb cpuid flag to guest):
If hardware support the pdpe1gb flag, expose it to guest by default.
Users don't have to use a 'cpuid= ' option in config file to turn
it on.
I don't understand
On 17.11.14 at 17:43, rcojoc...@bitdefender.com wrote:
On 11/17/2014 06:37 PM, Jan Beulich wrote:
On 12.11.14 at 16:48, andrew.coop...@citrix.com wrote:
On 12/11/14 15:31, Tamas K Lengyel wrote:
xen/include/public/domctl.h | 44 +--
xen/include/public/hvm/params.h | 2
On 17.11.14 at 18:06, tamas.leng...@zentific.com wrote:
On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich jbeul...@suse.com wrote:
On 12.11.14 at 16:48, andrew.coop...@citrix.com wrote:
On 12/11/14 15:31, Tamas K Lengyel wrote:
xen/include/public/domctl.h | 44 +--
xen/include
On 17.11.14 at 23:40, li...@eikelenboom.it wrote:
OK, i still don't get why the output of debug-key 'i' reports +47 as pirq
here instead of the guest value
(g_gsi of for this legacy interrupt which is 40 ?), like it does when it's a
MSI with the PIRQ ?
No - as you said yourself, it's a
On 17.11.14 at 19:01, li...@eikelenboom.it wrote:
(XEN) [2014-11-17 17:54:18.695] CPU00:
(XEN) [2014-11-17 17:54:18.705] CPU01:
(XEN) [2014-11-17 17:54:18.716] d16 OK-softirq 62msec ago, state:1, 2628
count,
[prev:83054ef57e70, next:83054ef57e70] 83051b904428NULL
MAPPED_SHIFT
On 18.11.14 at 09:16, tiejun.c...@intel.com wrote:
On 2014/11/18 16:01, Jan Beulich wrote:
On 18.11.14 at 04:08, tiejun.c...@intel.com wrote:
Here I tried to implement what you want. Note just pick two key
fragments since others have no big deal.
#1:
@@ -898,14 +898,25 @@ int
On 18.11.14 at 16:00, julien.gr...@linaro.org wrote:
On 10/31/2014 09:02 AM, Jan Beulich wrote:
On 30.10.14 at 19:51, julien.gr...@linaro.org wrote:
The naming suggests that the #if really should be around just the
gic_version field (with a dummy field in the #else case to be C89
compatible
On 18.11.14 at 17:24, furryfutt...@gmail.com wrote:
Hello Jan,
Friday, November 14, 2014, 5:27:36 AM, you wrote:
I implied your earlier statement to mean that. But - did you also
verify that the three flags actually end up set (ideally from both
DomU and Dom0 perspective)? The PCI
On 19.11.14 at 02:26, tiejun.c...@intel.com wrote:
So without lookuping devices[i], how can we call func() for each sbdf as
you mentioned?
You've got both rmrr and bdf in the body of for_each_rmrr_device().
After all - as I said - you just open-coded it.
Yeah, so change this again,
On 20.11.14 at 02:23, sfl...@ihonk.com wrote:
On 11/17/2014 23:54, Jan Beulich wrote:
Another thing - now that serial logging appears to be working for
you, did you try whether the host, once hung, still reacts to serial
input (perhaps force input to go to Xen right at boot via the
conswitch
On 19.11.14 at 17:44, konrad.w...@oracle.com wrote:
On Fri, Nov 14, 2014 at 11:11:46AM -0500, Konrad Rzeszutek Wilk wrote:
On Fri, Nov 14, 2014 at 03:13:42PM +, Jan Beulich wrote:
On 12.11.14 at 03:23, konrad.w...@oracle.com wrote:
+static void pt_pirq_softirq_reset(struct
On 19.11.14 at 16:12, furryfutt...@gmail.com wrote:
This is getting more interesting. It seems that something is
overwriting the pci-back configuration data.
Starting from a fresh reboot I checked the Dom0 pci configuration and
got this:
root@smartin-xen:~# lspci -s 00:19.0 -x
the chances
of them getting abused. Not unduly crashing the guest (as done
in the third one) may avoid future security issues of guest user
mode affecting the guest kernel.
Signed-off-by: Jan Beulich jbeul...@suse.com
___
Xen-devel mailing list
Xen-devel
MMU_MACHPHYS_UPDATE, not manipulating page tables, shouldn't ignore
a bad page table domain being specified.
Also pt_owner can't be NULL when reaching the out label, so the
respective check can be dropped.
Signed-off-by: Jan Beulich jbeul...@suse.com
Acked-by: Tim Deegan t...@xen.org
--- a/xen
the
respective logic is being adjusted at once, together with a little
other related cleanup.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3062,23 +3062,23 @@ long do_mmuext_op(
}
case MMUEXT_NEW_BASEPTR
On 19.11.14 at 23:21, konrad.w...@oracle.com wrote:
@@ -97,13 +97,15 @@ bool_t pt_pirq_softirq_active(struct hvm_pirq_dpci
*pirq_dpci)
}
/*
- * Reset the pirq_dpci-dom parameter to NULL.
+ * Cancels an outstanding pirq_dpci (if scheduled). Also if clear is set,
+ * reset
On 19.11.14 at 23:21, konrad.w...@oracle.com wrote:
Leaving aside the question of whether this is the right approach, in
case it is a couple of comments:
@@ -85,7 +91,7 @@ static void raise_softirq_for(struct hvm_pirq_dpci
*pirq_dpci)
*/
bool_t pt_pirq_softirq_active(struct
that uses the maximum MFN to calculate
the DMA mask.
Signed-off-by: David Vrabel david.vra...@citrix.com
Reviewed-by: Jan Beulich jbeul...@suse.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 20.11.14 at 12:34, t...@xen.org wrote:
At 11:13 +0100 on 20 Nov (1416478386), Jan Beulich wrote:
This extends commit 5283b310 (x86/HVM: only kill guest when unknown VM
exit occurred in guest kernel mode) to further cases, including the
failed VM entry one that XSA-110 was needed
On 18.11.14 at 20:20, julien.gr...@linaro.org wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -540,6 +540,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
int i, j, e820_warn = 0, bytes = 0;
bool_t acpi_boot_table_init_done = 0;
struct domain *dom0;
On 20.11.14 at 15:40, kevin.t...@intel.com wrote:
From: Tian, Kevin
Sent: Thursday, November 20, 2014 4:51 PM
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, November 20, 2014 4:04 PM
On 20.11.14 at 08:45, kevin.t...@intel.com wrote:
Current option sounds a reasonable
On 20.11.14 at 20:51, konrad.w...@oracle.com wrote:
@@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d, struct
hvm_pirq_dpci *pirq_dpci)
ASSERT(d-arch.hvm_domain.irq.dpci);
spin_lock(d-event_lock);
-if ( pirq_dpci-state )
+if (
On 21.11.14 at 08:43, kevin.t...@intel.com wrote:
From: Chen, Tiejun
Sent: Friday, November 21, 2014 2:26 PM
On 2014/11/3 18:02, Jan Beulich wrote:
On 03.11.14 at 10:55, tiejun.c...@intel.com wrote:
On 2014/11/3 17:45, Jan Beulich wrote:
On 03.11.14 at 10:32, tiejun.c...@intel.com
On 20.11.14 at 21:07, sfl...@ihonk.com wrote:
Running with mwait-idle=0 solves (hides?) the problem. Next step is to
fiddle with the C states?
So this also prompted me to go over the list of errata. Just to confirm
- your CPU is family 6 model 44? What stepping? And what nominal
frequency?
On 20.11.14 at 19:28, andrew.coop...@citrix.com wrote:
Should the guest change the p2m structure during live migration, the
toolstack ends up with a stale p2m with a non-p2m frame in the middle,
resulting in bogus cross-referencing. Should the guest change an entry
in the p2m, the p2m frame
On 21.11.14 at 14:37, jgr...@suse.com wrote:
On 11/21/2014 02:26 PM, Andrew Cooper wrote:
On 21/11/14 12:57, Juergen Gross wrote:
On 11/21/2014 01:23 PM, Jan Beulich wrote:
On 14.11.14 at 10:37, jgr...@suse.com.non-mime.internet wrote:
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen
On 21.11.14 at 15:39, jgr...@suse.com wrote:
Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
wrong device to the domain. The MMIO address was too large for a
MFN of a 32-bit system (it was 38000320-3800036f).
Instead of rejecting the operation Xen tried to perform
On 21.11.14 at 16:01, andrew.coop...@citrix.com wrote:
On 21/11/14 14:54, Jan Beulich wrote:
On 21.11.14 at 15:39, jgr...@suse.com wrote:
Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
wrong device to the domain. The MMIO address was too large for a
MFN of a 32-bit system
On 21.11.14 at 16:17, jgr...@suse.com wrote:
On 11/21/2014 03:54 PM, Jan Beulich wrote:
On 21.11.14 at 15:39, jgr...@suse.com wrote:
Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
wrong device to the domain. The MMIO address was too large for a
MFN of a 32-bit system
On 21.11.14 at 16:14, konrad.w...@oracle.com wrote:
On Fri, Nov 21, 2014 at 01:03:43PM +0100, Jan Beulich wrote:
On 21.11.14 at 12:50, konrad.w...@oracle.com wrote:
On November 21, 2014 2:51:33 AM EST, Jan Beulich jbeul...@suse.com wrote:
On 20.11.14 at 20:51, konrad.w...@oracle.com wrote
On 21.11.14 at 16:06, wei.l...@citrix.com wrote:
Signed-off-by: Elena Ufimsteva ufimts...@gmail.com
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
---
xen/arch/x86/numa.c | 46 +-
1 file changed, 45 insertions
On 21.11.14 at 17:35, wei.l...@citrix.com wrote:
On Fri, Nov 21, 2014 at 04:25:34PM +, Jan Beulich wrote:
On 21.11.14 at 16:06, wei.l...@citrix.com wrote:
vnuma_vdistances = [10, 30] # optional
Being optional, would the real distances be used instead? And what
Default value of [10
On 21.11.14 at 17:55, wei.l...@citrix.com wrote:
Nonetheless I'm all for having a configuration option that would meet
both present and future need. Do you have anything in mind? Are you
suggesting we should allow specifying every element in SLIT in xl?
I think that would be desirable.
Jan
On 21.11.14 at 23:03, konrad.w...@oracle.com wrote:
I rewrote it a bit to be more in the style of pciback:
[...]
[v2: Removed the switch statement, moved it about]
What you don't mention here is that you also removed the outer
loop, yet that breaks functionality afaict: There can (and I
On 23.11.14 at 02:28, sfl...@ihonk.com wrote:
With mwait-idle=0:
(XEN) 'c' pressed - printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state: C0
(XEN) max_cstate: C7
(XEN) states:
(XEN) C1: type[C1] latency[001] usage[] method[ FFH]
On 21.11.14 at 17:45, konrad.w...@oracle.com wrote:
From 90d00db0949a8e796d7f812134753a54b2fe3d51 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Thu, 20 Nov 2014 14:28:11 -0500
Subject: [PATCH] dpci: Add 'masked' as an gate for hvm_dirq_assist to
process.
On 21.11.14 at 20:56, konrad.w...@oracle.com wrote:
On Fri, Nov 21, 2014 at 03:06:56PM +, Wei Liu wrote:
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -88,6 +88,19 @@ void pci_setup(void)
printf(Relocating guest memory for lowmem MMIO space %s\n,
On 21.11.14 at 16:06, wei.l...@citrix.com wrote:
Signed-off-by: Wei Liu wei.l...@citrix.com
So this is the fourth patch now without any description whatsoever.
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -88,6 +88,19 @@ void pci_setup(void)
On 24.11.14 at 10:08, sfl...@ihonk.com wrote:
On Nov 24, 2014, at 00:45, Jan Beulich jbeul...@suse.com wrote:
On 23.11.14 at 02:28, sfl...@ihonk.com wrote:
With mwait-idle=0:
(XEN) 'c' pressed - printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state: C0
(XEN
checking (as done in the first two patches) reduces the chances
of them getting abused. Not unduly crashing the guest (as done
in the third one) may avoid future security issues of guest user
mode affecting the guest kernel.
Signed-off-by: Jan Beulich jbeul...@suse.com
Hi Konrad - looks like I
On 24.11.14 at 13:43, dunl...@umich.edu wrote:
On Thu, Nov 20, 2014 at 10:12 AM, Jan Beulich jbeul...@suse.com wrote:
Instead properly fail requests that shouldn't be issued on foreign
domains or - for MMUEXT_{CLEAR,COPY}_PAGE - extend the existing
operation to work that way.
I take
On 25.11.14 at 08:44, jgr...@suse.com wrote:
Hi,
make clean in xen-unstable is failing:
make[2]: Entering directory '/home/gross/xen/tools'
set -e; if test -d qemu-xen-traditional-dir/.; then \
make -C qemu-xen-traditional-dir clean; \
fi
make[3]: Entering directory
On 25.11.14 at 11:08, andrew.coop...@citrix.com wrote:
A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
As a result, injecting a fault and retrying the the vmentry is likely to
fail
in the same way.
That's not all that unlikely - remember that the change was
On 25.11.14 at 10:38, sfl...@ihonk.com wrote:
On 11/25/2014 12:16 AM, Jan Beulich wrote:
Interesting, so other than for me (perhaps due to other patches
I have in my tree) the change resulted in C states now being used
again despite mwait-idle=0, which is good. Question now
On 25.11.14 at 11:46, andrew.coop...@citrix.com wrote:
On 25/11/14 10:42, Jan Beulich wrote:
On 25.11.14 at 11:08, andrew.coop...@citrix.com wrote:
A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS
state.
As a result, injecting a fault and retrying the the vmentry
On 25.11.14 at 11:58, andrew.coop...@citrix.com wrote:
On 25/11/14 10:46, Andrew Cooper wrote:
On 25/11/14 10:42, Jan Beulich wrote:
On 25.11.14 at 11:08, andrew.coop...@citrix.com wrote:
A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS
state.
As a result, injecting
On 25.11.14 at 13:10, andrew.coop...@citrix.com wrote:
On 25/11/14 11:31, Jan Beulich wrote:
On 25.11.14 at 11:58, andrew.coop...@citrix.com wrote:
On 25/11/14 10:46, Andrew Cooper wrote:
On 25/11/14 10:42, Jan Beulich wrote:
On 25.11.14 at 11:08, andrew.coop...@citrix.com wrote:
A failed
No-one (including me) paid attention during review that these
structures don't adhere to the naming requirements of the public
interface: Consistently use xen_ prefixes at least for all new
additions.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/tools/libxc/include/xenctrl.h
+++ b/tools
On 17.11.14 at 00:07, boris.ostrov...@oracle.com wrote:
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -103,6 +103,10 @@
!vcpu_set_singleshot_timer vcpu.h
?xenoprof_init xenoprof.h
?xenoprof_passivexenoprof.h
+?
On 17.11.14 at 00:07, boris.ostrov...@oracle.com wrote:
@@ -278,3 +290,139 @@ void vpmu_dump(struct vcpu *v)
vpmu-arch_vpmu_ops-arch_vpmu_dump(v);
}
+static s_time_t vpmu_start_ctxt_switch;
Blank line here please.
+static long vpmu_sched_checkin(void *arg)
+{
+int cpu =
On 17.11.14 at 00:07, boris.ostrov...@oracle.com wrote:
@@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
switch ( vendor )
{
case X86_VENDOR_AMD:
-if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
-opt_vpmu_enabled = 0;
+if (
+
- sizeof(struct xen_pmu_cntr_pair) *
- arch_pmc_cnt);
-p = xzalloc(uint64_t);
At least it was that way before...
With that fixed, feel free to add
Acked-by: Jan Beulich jbeul...@suse.com
Jan
___
Xen-devel
hardware treats it (CPL != 0 meaning user, rather
than CPL == 3)? Maybe you should surface CPL instead of a
boolean flag?
Anyway, with or without the adjustments (unless you go a 3rd
way)
Acked-by: Jan Beulich jbeul...@suse.com
Jan
___
Xen-devel mailing list
On 07.10.14 at 15:10, vkuzn...@redhat.com wrote:
New operation sets the 'recipient' domain which will recieve all
memory pages from a particular domain when these pages are freed.
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1152,6 +1152,33 @@ long
On 25.11.14 at 15:38, boris.ostrov...@oracle.com wrote:
On 11/25/2014 03:45 AM, Jan Beulich wrote:
@@ -1429,6 +1429,12 @@ int vlapic_init(struct vcpu *v)
HVM_DBG_LOG(DBG_LEVEL_VLAPIC, %d, v-vcpu_id);
+if ( is_pvh_vcpu(v) )
+{
+vlapic-hw.disabled
On 25.11.14 at 16:41, vkuzn...@redhat.com wrote:
Jan Beulich jbeul...@suse.com writes:
On 07.10.14 at 15:10, vkuzn...@redhat.com wrote:
@@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg,
unsigned int order)
scrub = 1;
}
-if ( unlikely
On 25.11.14 at 17:54, andrew.coop...@citrix.com wrote:
This is RFC as there is still a niggle. I tested this via a partial revert of
the XSA-110 fix but the result is quite chatty given a double VMCB dump and
domain crash. However, I am not sure we want to make any vmentry failure
quite, as
the the
vmentry is likely to fail in the same way.
Reported-by: Andrew Cooper andrew.coop...@citrix.com
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2338,6 +2338,7 @@ void svm_vmexit_handler(struct cpu_user_
struct
On 25.11.14 at 18:10, vkuzn...@redhat.com wrote:
Jan Beulich jbeul...@suse.com writes:
On 25.11.14 at 16:41, vkuzn...@redhat.com wrote:
Jan Beulich jbeul...@suse.com writes:
On 07.10.14 at 15:10, vkuzn...@redhat.com wrote:
@@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info
On 26.11.14 at 15:32, boris.ostrov...@oracle.com wrote:
On 11/25/2014 08:49 AM, Jan Beulich wrote:
On 17.11.14 at 00:07, boris.ostrov...@oracle.com wrote:
@@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
switch ( vendor )
{
case X86_VENDOR_AMD
On 26.11.14 at 15:39, boris.ostrov...@oracle.com wrote:
On 11/25/2014 09:28 AM, Jan Beulich wrote:
+else
+{
+struct segment_register seg;
+
+hvm_get_segment_register(sampled, x86_seg_cs, seg);
+r-cs = seg.sel
On 27.11.14 at 06:29, sfl...@ihonk.com wrote:
On 11/25/2014 03:00 AM, Jan Beulich wrote:
Okay, so it's not really the mwait-idle driver causing the regression,
but it is C-state related. Hence we're now down to seeing whether all
or just the deeper C states are affected, i.e. I now need
On 25.11.14 at 19:05, dgde...@tycho.nsa.gov wrote:
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -135,6 +135,19 @@ static int get_irq_sid(int irq, u32 *sid, struct
avc_audit_data *ad)
return 0;
}
+static int avc_unknown_permission(const char* name, int id)
const
On 27.11.14 at 11:26, t...@xen.org wrote:
At 08:42 + on 27 Nov (1417074133), Jan Beulich wrote:
On 26.11.14 at 18:43, andrew.coop...@citrix.com wrote:
My v1 patch only fixes the VMX side of things. SVM doesn't explicitly
identify a failed vmentry and lets it fall into the default case
On 27.11.14 at 12:29, t...@xen.org wrote:
At 11:16 + on 27 Nov (1417083414), Jan Beulich wrote:
On 27.11.14 at 11:26, t...@xen.org wrote:
At 08:42 + on 27 Nov (1417074133), Jan Beulich wrote:
On 26.11.14 at 18:43, andrew.coop...@citrix.com wrote:
My v1 patch only fixes the VMX
On 27.11.14 at 13:46, andrew.coop...@citrix.com wrote:
On 27/11/14 12:39, Jan Beulich wrote:
if ( unlikely(exit_reason == VMEXIT_INVALID) )
{
I think it would be good to retain the printk here from previous
versions of the patch, specifically identifies the below vmcb dump
On 28.11.14 at 04:28, liang.z...@intel.com wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4287,7 +4287,7 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
unsigned int *ebx,
!host_tsc_is_safe() )
*edx =
On 28.11.14 at 10:07, ian.jack...@eu.citrix.com wrote:
flight 31882 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31882/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 17
On 28.11.14 at 08:59, yu.c.zh...@linux.intel.com wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2838,7 +2838,8 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
long gla,
* to the mmio handler.
*/
if ( (p2mt == p2m_mmio_dm) ||
-
On 28.11.14 at 11:29, liang.z...@intel.com wrote:
-if (!hvm_pse1gb_supported(d))
+if (!hvm_pse1gb_supported(d) || paging_mode_shadow(d))
*edx = ~cpufeat_mask(X86_FEATURE_PAGE1GB);
With
#define hvm_pse1gb_supported(d) \
(cpu_has_page1gb paging_mode_hap(d))
in the function hvm_cpuid(). So the change is
okay for shadow mode case.
Signed-off-by: Liang Li liang.z...@intel.com
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
Reviewed-by: Jan Beulich jbeul...@suse.com
___
Xen-devel mailing list
Xen-devel
On 28.11.14 at 12:36, andrew.coop...@citrix.com wrote:
However, it occurs to me that HVMOP_op_mask absolutely must live in the
public header files, as it is guest visible, and forms part of the ABI.
Consider a userspace task which falls into a continuation, is preempted
and paused by the
On 28.11.14 at 14:55, andrew.coop...@citrix.com wrote:
The problem is with continuations which reuse the upper bits of the
input register, not with this HVMOP_op_mask specifically; the
HVMOP_op_mask simply adds to an existing problem. This is something
which needs considering urgently
On 01.12.14 at 09:49, yu.c.zh...@linux.intel.com wrote:
On 11/28/2014 5:57 PM, Jan Beulich wrote:
On 28.11.14 at 08:59, yu.c.zh...@linux.intel.com wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2838,7 +2838,8 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
long
On 01.12.14 at 10:29, jgr...@suse.com wrote:
The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
currently contains the mfn of the top level page frame of the 3 level
p2m tree, which is used by the Xen tools during saving and restoring
(and live migration) of pv domains and for
On 01.12.14 at 11:30, t...@xen.org wrote:
At 09:32 + on 01 Dec (1417422746), Jan Beulich wrote:
On 01.12.14 at 09:49, yu.c.zh...@linux.intel.com wrote:
To my understanding, pages with p2m_ram_ro are not supposed to be
modified by guest. So in __hvm_copy(), when p2m type of a page
On 01.12.14 at 12:19, david.vra...@citrix.com wrote:
On 01/12/14 10:15, Jan Beulich wrote:
On 01.12.14 at 10:29, jgr...@suse.com wrote:
The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
currently contains the mfn of the top level page frame of the 3 level
p2m tree, which
On 01.12.14 at 13:13, t...@xen.org wrote:
At 11:17 + on 01 Dec (1417429027), Jan Beulich wrote:
On 01.12.14 at 11:30, t...@xen.org wrote:
At 09:32 + on 01 Dec (1417422746), Jan Beulich wrote:
On 01.12.14 at 09:49, yu.c.zh...@linux.intel.com wrote:
To my understanding, pages
On 02.12.14 at 08:48, yu.c.zh...@linux.intel.com wrote:
On 12/1/2014 8:31 PM, Jan Beulich wrote:
On 01.12.14 at 13:13, t...@xen.org wrote:
At 11:17 + on 01 Dec (1417429027), Jan Beulich wrote:
On 01.12.14 at 11:30, t...@xen.org wrote:
At 09:32 + on 01 Dec (1417422746), Jan Beulich
On 01.12.14 at 20:22, stefano.stabell...@eu.citrix.com wrote:
xc_physdev_unmap_pirq might revoke the permission to map the irq from
the domain causing the following xc_domain_irq_permission call to fail
and return error (domain_pirq_to_irq returns 0).
Apart from the patch title being rather
1 - 100 of 13153 matches
Mail list logo
