flight 32298 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32298/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-win7-amd64 7 windows-install fail REGR. vs. 32231
Regressions which
flight 32291 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32291/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-i386-i386-pair 17 guest-migrate/src_host/dst_host fail like 31897
test-amd64-i386-pair
flight 32294 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32294/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 8 xen-boot/dst_host fail REGR. vs. 32194
Tests which did not
Hi Elena/Boris:
Actually, I forgot I had already made and tested AMD SVM and other changes
for domU support, please find the patches.
So the only thing remaining for AMD would be iommu support and SVM vmexit
for CR reads and writes which currently calls handle_mmio (which patch #3
attempted, bu
Certain IOIO instructions and CR access instructions like
lmsw/clts etc need to be emulated. handle_mmio is incorrectly called to
accomplish this. Create svm_emulate() to call hvm_emulate_one which is more
appropriate, and works for pvh as well. handle_mmio call is
forbidden for pvh.
Signed-off-by
On AMD, MSR_AMD64_TSC_RATIO must be set for rdtsc instruction in guest
to properly read the cpu tsc. To that end, set tsc_khz in struct domain.
Signed-off-by: Mukesh Rathor
---
xen/arch/x86/time.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index
Finally, enable pvh if the cpu supports NPT and svm decode.
Signed-off-by: Mukesh Rathor
---
xen/arch/x86/hvm/svm/svm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 4bb4ff2..8b27a76 100644
--- a/xen/arch/x86/hvm/svm/svm.c
++
PVH guest starts in Long 64bit paging mode. This patch modifies
construct_vmcb for that.
Signed-off-by: Mukesh Rathor
---
xen/arch/x86/hvm/svm/vmcb.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
Call pv_cpuid for pvh cpuid intercept. Note, we modify
svm_vmexit_do_cpuid instead of the intercept switch because the guest
eip needs to be adjusted for pvh also.
Signed-off-by: Mukesh Rathor
---
xen/arch/x86/hvm/svm/svm.c | 24 ++--
1 file changed, 14 insertions(+), 10 dele
PVH doesn't use apic emulation hence vlapic->regs ptr is not set for it.
Signed-off-by: Mukesh Rathor
---
xen/arch/x86/hvm/svm/svm.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index dac16
Instead of tracking down which commit involving libxl* which prints all kind of
noiseto stderr, I will post a workaround.
If you build, install, and use 4.5 this bug will drive you mad, so here it is:
snip -
--- a/tools/hotplug/Linux/xendomains.in+++ b/tools/
flight 32285 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32285/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-sedf 5 xen-bootfail pass in 32215
test-amd64-amd64-xl-qemut-winxpsp3 3 ho
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
flight 32282 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32282/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32110
test-amd64-amd64-xl-qemut-
We need to make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try dereference it in
the future, when VCPU is gone.
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/hvm/vpmu.c | 22 ++
1 files changed, 22 insertions(+), 0 deletion
I am testing 4.5 (HEAD) in deb8 and noticed some problems with xendomains(git
path): ./tools/hotplug/Linux/xendomains
when trying to get the name from the JSON config it ends up with the symlink
name instead. Thismay not show up as a bug unless you use symlinks in
/etc/xen/auto, like me.
I thi
`font` had a trailing single quote which was out of place.
`gnttab_max_frames` was missing escapes for the underscores which caused the
underscores to take their markdown meaning, causing 'max' in the middle to be
italicised. Escape the underscores, and make all command line parameters
bold, to b
(adding Ian J who knows a bit more about C xenstored than me...)
On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
> Hello Ian,
>
> On 12.12.2014 17:56, Ian Campbell wrote:
> > On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
> >> On 12.12.2014 17:32, Ian Campbell wrote:
> >>> On Fri,
On 12/12/14 13:17, Juergen Gross wrote:
>
>
> As a first draft I'd suggest the following:
Some rough thoughts below.
> Option Selects Depends
> --
> XEN SWIOT
Hello Ian,
On 12.12.2014 17:56, Ian Campbell wrote:
> On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
>> On 12.12.2014 17:32, Ian Campbell wrote:
>>> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
We did enable tracing and now have the xenstored-trace.log of one crash:
It
On 12/12/14 14:43, Julien Grall wrote:
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 7221bc8..7d14377 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -543,10 +543,17 @@ int arch_domain_create(struct domain *d, unsigned int
> domcr_flags)
> if ( (
On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
> Hello Ian,
>
> On 12.12.2014 17:32, Ian Campbell wrote:
> > On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
> >> We did enable tracing and now have the xenstored-trace.log of one crash:
> >> It contains 1.6 billion lines and is 83 GiB
On Fri, Dec 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote:
> Hi Konrad,
>
> This doesn't seem to be applied yet, nor does it seem to have a
> release-(N)ACK
> from you ?
Hm, Stefano:
- Is this a regression?
- What are the risks of this not going in? I presume that it just means
we
Hello Ian,
On 12.12.2014 17:32, Ian Campbell wrote:
> On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
>> We did enable tracing and now have the xenstored-trace.log of one crash:
>> It contains 1.6 billion lines and is 83 GiB.
>> It just shows xenstored to crash on TRANSACTION_START.
>>
>> I
On Fri, Dec 12, 2014 at 02:17:27PM +0100, Juergen Gross wrote:
> Hi,
>
> This is a design proposal for a rework of the config options on the
> Linux kernel which are related to Xen.
>
> The need to do so arose from the fact that it is currently not
> possible to build the Xen frontend drivers for
On Fri, Dec 12, 2014 at 09:45:17AM +, Jan Beulich wrote:
> >>> On 11.12.14 at 20:41, wrote:
> > On Thu, Dec 11, 2014 at 03:38:39PM +, Jan Beulich wrote:
> >> >>> On 11.12.14 at 16:18, wrote:
> >> > A proper fix would be to automatically adjust based on memmap and CPU
> >> > but
> >> > t
On Fri, 2014-12-12 at 10:24 +, Jan Beulich wrote:
> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> wasn't really consistent in one respect: The granting of access to an
> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> domains. In fact it is wro
On Fri, 2014-12-12 at 17:14 +0100, Philipp Hahn wrote:
> Hello,
>
> On 13.11.2014 10:12, Ian Campbell wrote:
> > On Thu, 2014-11-13 at 08:45 +0100, Philipp Hahn wrote:
> >> To me this looks like some memory corruption by some unknown code
> >> writing into some random memory space, which happens t
flight 32278 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32278/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 8 guest-start fail REGR. vs. 31241
test-amd64-amd64-rump
On Tue, 2014-12-09 at 20:46 -0700, Chun Yan Liu wrote:
>
> >>> On 12/9/2014 at 07:11 PM, in message
> >>> <1418123518.14361.20.ca...@citrix.com>,
> Ian Campbell wrote:
> > On Mon, 2014-12-08 at 22:04 -0700, Chun Yan Liu wrote:
> > > Partly. At least for domain disk snapshot create/delete, I pr
Hello,
On 13.11.2014 10:12, Ian Campbell wrote:
> On Thu, 2014-11-13 at 08:45 +0100, Philipp Hahn wrote:
>> To me this looks like some memory corruption by some unknown code
>> writing into some random memory space, which happens to be the tdb here.
>
> I wonder if running xenstored under valgrin
On Fri, 2014-12-12 at 15:59 +, Ian Campbell wrote:
> On Mon, 2014-12-08 at 15:47 +, Frediano Ziglio wrote:
> > Hi,
> > while I was porting D01 platform
> > (https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
> > trying to describe the step I made and problems I encountere
On Mon, 2014-12-08 at 15:47 +, Frediano Ziglio wrote:
> Hi,
> while I was porting D01 platform
> (https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
> trying to describe the step I made and problems I encountered hoping
> it could useful to other people. The idea is to put su
Hi Konrad,
This doesn't seem to be applied yet, nor does it seem to have a release-(N)ACK
from you ?
--
Sander
Friday, November 28, 2014, 5:53:09 PM, you wrote:
> On do_pci_remove when QEMU returns error, we just bail out early without
> resetting the device. On domain shutdown we are racing
On Fri, Dec 12, Olaf Hering wrote:
> This works:
> ExecStart=@XENSTORED@ --no-fork $XENSTORED_ARGS
>
> This fails:
> ExecStart=$XENSTORED --no-fork $XENSTORED_ARGS
But this will likely work:
ExecStart=/usr/bin/env $XENSTORED --no-fork $XENSTORED_ARGS
Let me know how to proceed...
Olaf
__
On 12/12/14 12:27, Chao Peng wrote:
> Hi all, we plan to bring Intel CAT into XEN. This is the initial
> design for that. Comments/suggestions are welcome.
>
> Background
> ==
> Traditionally, all Virtual Machines ("VMs") share the same set of system
> cache resources. There is no hardware
Use the new vgic interface to know which virtual PPI is free and use it
for the event channel code.
At the DOM0 creation time, Xen still don't know which vIRQ will be free.
All the vIRQ will be reserved when we parse the device tree. So allocate
when the hypervisor node is created.
It's safe to d
The field nr_lines in the arch_domain vgic structure contains the number of
SPIs for the emulated GIC. Using the nr_lines make confusion with the GIC
code, where it means the number of IRQs. This can lead to coding error.
Also introduce vgic_nr_lines to get the number of IRQ handled by the emulate
While it's easy to know which hardware IRQ is assigned to a domain, there
is no way to know which IRQ is emulated by Xen for a specific domain.
Introduce a bitmap to keep track of every vIRQ used by a domain. This
will be used later to find free vIRQ for interrupt device assignment and
emulated in
This help for guest interrupts debugging. If the vIRQ is not allocate,
this means that nothing is wired to it.
Signed-off-by: Julien Grall
---
xen/arch/arm/vgic.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index dbfc259..719cb9f 100644
--- a
Hello,
This patch series replaces the per-platform hardcoded event channel interrupt
to a generic solution. It will make the port to a new platform more easier and
may avoid to introduce per-platform code with the new upcoming ACPI support.
This could be done by keeping track of vIRQ (emulated an
> -Original Message-
> From: Matt Wilson [mailto:mswil...@gmail.com] On Behalf Of Matt Wilson
> Sent: 11 December 2014 23:17
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: Extend HVM cpuid leaf with
> vcpu id
>
>
Hi,
This is a design proposal for a rework of the config options on the
Linux kernel which are related to Xen.
The need to do so arose from the fact that it is currently not
possible to build the Xen frontend drivers for a non-pvops kernel,
e.g. to run them in a HVM-domain. There are more drawba
Hi all, we plan to bring Intel CAT into XEN. This is the initial
design for that. Comments/suggestions are welcome.
Background
==
Traditionally, all Virtual Machines ("VMs") share the same set of system
cache resources. There is no hardware support to control allocation or
availability of
On Fri, Dec 12, Olaf Hering wrote:
> On Fri, Dec 12, Ian Campbell wrote:
>
> > Seems ok. I wonder if the wrapper ought to source
> > @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
> > rather than relying on the initscript and unit file to do so. Especially
> > in the inits
On Fri, 12 Dec 2014, Ian Campbell wrote:
On Fri, 2014-12-12 at 12:37 +0100, Olaf Hering wrote:
On Fri, Dec 12, Ian Campbell wrote:
Seems ok. I wonder if the wrapper ought to source
@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
rather than relying on the initscript a
flight 32245 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32245/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32198
Tests which did not succeed,
On Fri, 2014-12-12 at 12:37 +0100, Olaf Hering wrote:
> On Fri, Dec 12, Ian Campbell wrote:
>
> > Seems ok. I wonder if the wrapper ought to source
> > @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
> > rather than relying on the initscript and unit file to do so. Especiall
flight 32277 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32277/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303
Tests which are failin
On Fri, Dec 12, Ian Campbell wrote:
> Seems ok. I wonder if the wrapper ought to source
> @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
> rather than relying on the initscript and unit file to do so. Especially
> in the initscript case it looks a bit ugly to have to manual
On Fri, 2014-12-12 at 11:03 +, Jan Beulich wrote:
> >>> On 12.12.14 at 11:49, wrote:
> > On 12/12/14 10:24, Jan Beulich wrote:
> >> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> >> wasn't really consistent in one respect: The granting of access to an
> >> IRQ shouldn
On Thu, 2014-12-11 at 10:02 -0800, manish jaggi wrote:
> This is the complete smmu.c file which you can refer for PCI
> passthrough (http://pastebin.com/QDX8fpDu)
I'm afraid that as Julien says this is basically no help.
> Just FYI this is not a patch, we are still testing on our board and
> can
>>> On 12.12.14 at 11:49, wrote:
> On 12/12/14 10:24, Jan Beulich wrote:
>> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
>> wasn't really consistent in one respect: The granting of access to an
>> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
>> do
>>> On 12.12.14 at 08:24, wrote:
> - is there existing _map_ call for this purpose per your knowledge, or
> a new one is required? If the latter, what's the additional logic to be
> implemented there?
I think the answer to this depends on whether you want to use
grants. The goal of using the nati
On 12/12/14 10:24, Jan Beulich wrote:
> Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
> wasn't really consistent in one respect: The granting of access to an
> IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
> domains. In fact it is wrong to assume tha
Commit 545607eb3c ("x86: fix various issues with handling guest IRQs")
wasn't really consistent in one respect: The granting of access to an
IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both
domains. In fact it is wrong to assume that a translation is already/
still in place at
On Wed, 2014-12-10 at 18:52 +0100, Olaf Hering wrote:
> On Wed, Dec 10, Ian Campbell wrote:
>
> > That results in a wrapper which unconditionally execs, the systemd unit
> > just calls that while the sysv script runs the wrapper and then does the
> > xenstore-read -s loop.
>
> Since systemd hand
On Wed, 2014-12-10 at 19:01 +0100, Olaf Hering wrote:
> On Wed, Dec 10, Ian Campbell wrote:
>
> > Separately from the above I wonder if it might be worth moving the
> > xenstore readiness check into the xen-init-dom0 helper and having most
> > things which currently depend on xenstore actually dep
>>> On 11.12.14 at 20:41, wrote:
> On Thu, Dec 11, 2014 at 03:38:39PM +, Jan Beulich wrote:
>> >>> On 11.12.14 at 16:18, wrote:
>> > A proper fix would be to automatically adjust based on memmap and CPU but
>> > that could be too complex.
>>
>> The problem isn't the complexity, but the chic
flight 32239 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32239/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl5 xen-boot fail REGR. vs. 32171
test-amd64-i386-libvir
XenGT (Intel Graphics Virtualization technology, please refer to
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-
xengt) driver runs inside Dom0 as a virtual graphics device model,
and needs to trap and emulate the guest's write operations to some
specific memory pages, like memory p
From: Yu Zhang
Currently, the P2M_RO_TYPES bears 2 meanings: one is
"_PAGE_RW bit is clear in their PTEs", and another is
to discard the write operations on these pages. This
patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
to bear the second meaning, so we can use this type
class instead of
From: Yu Zhang
A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's page tables. Handling of this new
p2m type are similar with existing p2m_ram_ro in most condition
checks, with only difference on final policy of emulation vs. drop.
For p2m_ram_ro types,
63 matches
Mail list logo
