On 01/29/2015 11:46 PM, Tamas K Lengyel wrote:
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index c7a0bde..3b58700 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1445,15 +1445,6 @@ void p2m_vm_event_emulate_check(struct vcpu *v, const
> vm_event_response
>>> On 1/30/2015 at 12:33 AM, in message <1422549191.5198.32.ca...@citrix.com>,
>>> Ian
Campbell wrote:
> On Mon, 2015-01-26 at 11:25 +0800, Chunyan Liu wrote:
>
> This is all looking good (including the previous two patches where I
> didn't have any substantial comments).
>
> > Use
When commit 6865e52b78f4, "PCI multi-seg: adjust domctl interface",
is introduced, we missed to sync that head file.
Signed-off-by: Tiejun Chen
---
tools/libxc/include/xenctrl.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libx
>>> On 1/30/2015 at 12:41 AM, in message <1422549669.10225.0.ca...@citrix.com>,
>>> Ian
Campbell wrote:
> On Mon, 2015-01-26 at 11:25 +0800, Chunyan Liu wrote:
> > Changes to V9:
> > * update libxl_disk_snapshot structures as Ian suggests
> > * add more descriptions for libxl_disk_snaps
branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-qemut-winxpsp3-vcpus1
test xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qe
flight 33892 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33892/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 11 guest-localmigrate fail REGR. vs. 33488
test-amd64
On 01/29/15 14:14, Don Slutz wrote:
> On 01/29/15 07:09, Paul Durrant wrote:
>>> -Original Message-
>>> From: Don Slutz [mailto:dsl...@verizon.com]
>>> Sent: 29 January 2015 00:58
>>> To: Don Slutz; Paul Durrant; qemu-de...@nongnu.org; Stefano Stabellini
>>> Cc: Peter Maydell; Olaf Hering;
flight 33885 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33885/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-credit25 xen-boot fail REGR. vs. 33835
test-amd64-i386-qemuu-
> > > I think that the xenstore_update function should be moved to a new file:
> > > we don't want xen_backend.c to be handling any frontend updates.
> > > Maybe you could create a new file, hw/xen/xen_pvdev.c?
> > >
> >
> > Stefano,
> > I'd like to create hw/xen/xen_pvdev.c , include/hw/xen/
From: "Luis R. Rodriguez"
There are several ways that a Xen system can update the
CPU microcode on a pvops kernel [0] now, the preferred way
is through the early microcode update mechanism. At run
time folks should use this new xenmicrocode tool and use
the same CPU microcode file as present on /
On Thu, Jan 29, 2015 at 08:15:16PM +0100, Borislav Petkov wrote:
> On Thu, Jan 29, 2015 at 04:21:05AM +0100, Luis R. Rodriguez wrote:
> > How close?
>
> As close as we can get but not closer - see the thing about updating
> microcode on Intel hyperthreaded logical cores in the other mail.
>
> We
On 2015/1/29 22:12, Bjorn Helgaas wrote:
> On Thu, Jan 29, 2015 at 7:15 AM, Jan Beulich wrote:
> On 29.01.15 at 04:54, wrote:
>>> --- a/drivers/pci/msi.c
>>> +++ b/drivers/pci/msi.c
>>> @@ -694,11 +694,16 @@ static void __iomem *msix_map_region(struct pci_dev
>>> *dev, unsigned nr_entries)
>
On 2015/1/29 18:50, Wei Liu wrote:
On Thu, Jan 29, 2015 at 08:41:24AM +0800, Chen, Tiejun wrote:
On 2015/1/28 19:12, Wei Liu wrote:
On Wed, Jan 28, 2015 at 08:42:56AM +0800, Chen, Tiejun wrote:
On 2015/1/27 22:40, Ian Jackson wrote:
Chen, Tiejun writes ("Re: [Qemu-devel] [RFC][PATCH 1/1] libx
Signed-off-by: Don Slutz
---
xen/arch/x86/hvm/hvm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c7984d1..6f7b407 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2573,6 +2573,7 @@ bool_t hvm_send_assist_req_to_ioreq
The 1st item is not data, but the port (address).
The 2nd item is the data.
Signed-off-by: Don Slutz
---
tools/xentrace/formats | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 089022a..51b652c 100644
--- a/tools/xe
This is not needed. However I provide it as it is used to generate
data in the cover letter.
Signed-off-by: Don Slutz
---
tools/xentrace/formats | 2 ++
xen/arch/x86/hvm/io.c | 4
xen/include/asm-x86/hvm/trace.h | 2 +-
xen/include/public/trace.h | 2 ++
4 files cha
This saves a VMENTRY and a VMEXIT since we not longer retry the
ioport read.
hvmemul_do_io() will retry in order to complete an ioport read when
hvm_send_assist_req() is successful.
Signed-off-by: Don Slutz
---
xen/arch/x86/hvm/hvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
Using a new enough QEMU that has:
commit 7665d6ba98e20fb05c420de947c1750fd47e5c07
Author: Paul Durrant
Date: Tue Jan 20 11:06:19 2015 +
Xen: Use the ioreq-server API when available
means that hvmloader and the guest will do pci config accesses that
will not be sent to QEMU. Howe
I.E. do just what no backing DM does.
Signed-off-by: Don Slutz
---
xen/arch/x86/hvm/emulate.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 2ed4344..e9fc070 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emul
Use the class to differentiate between host and nested p2m's, and
potentially other classes in the future.
Fix p2m class checks that implicitly assume nested and host are
the only two classes that will ever exist.
Signed-off-by: Ed White
Acked-by: Tim Deegan
---
Changes in v2:
- prepend m
On 29/01/2015 20:12, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 29, 2015 at 06:34:23PM +, Andrew Cooper wrote:
>>
>> Getting this conversation back on topic.
>>
>> The current state of play in Xen is this:
>>
>> * Boot time microcode loading exists (by scanning uncompressed cpio
>> multiboot m
On 29/01/2015 18:35, Julien Grall wrote:
> Hi Andrew,
>
> On 28/01/15 15:52, Andrew Cooper wrote:
>> c/s 5b5c40c0d1 "libxc: introduce a per architecture scratch pfn for temporary
>> grant mapping" accidentally an issue whereby there were two paths out of
>> xc_core_arch_get_scratch_gpfn() which ret
flight 33881 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33881/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-winxpsp3-vcpus1 5 xen-bootfail REGR. vs. 33815
Regressions which are
flight 33878 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33878/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 33480
test-amd64-i386-qem
In preparation for allowing for introspecting ARM and PV domains the old
control interface via the hvm_op hypercall is retired. A new control mechanism
is introduced via the domctl hypercall: monitor_op.
This patch aims to establish a base API on which future applications can build
on.
Suggested-
The flag is only used for debugging purposes, thus it should be only checked
for in debug builds of Xen.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 2 ++
xen/arch/x86/mm/p2m.c | 2 ++
xen/common/mem_access.c | 31 +++
3 files ch
This is the third and final patch in the mem_event -> vm_event renaming process
which removes all references and remaining code of mem_event from the Xen
source.
Signed-off-by: Tamas K Lengyel
---
MAINTAINERS| 1 -
docs/misc/xsm-flask.txt| 1 -
tools/libxc/Makefil
The spin-lock implementation in the xen-access test program is implemented
in a fashion that is actually incomplete. The x86 assembly that guarantees that
the lock is held by only one thread lacks the "lock;" instruction.
However, the spin-lock is not actually necessary in xen-access as it is not
The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This patch removes the dependency that mem_access nee
This is the second patch in the mem_event -> vm_event migration.
This patch migrates all previous use-cases of mem_event to use the
new vm_event system.
Signed-off-by: Tamas K Lengyel
---
MAINTAINERS | 2 +-
tools/libxc/xc_mem_event.c | 8 +--
tools/libxc/xc_
To make it easier to review the renaming process of mem_event -> vm_event,
the process is broken into three pieces, of which this patch is the first.
In this patch the vm_event subsystem is introduced and hooked into the build
process, but it is not yet used anywhere.
Signed-off-by: Tamas K Lengye
The name of the ring still implies it is used only for memory accesses,
which is no longer the case. It is also used to deliver variuos HVM events,
thus the name "monitor" is more appropriate in this setting.
Signed-off-by: Tamas K Lengyel
---
v3: Style and comment fixes.
---
tools/libxc/xc_doma
The current sanity check when enabling mem_event is only applicable
to mem_access.
Signed-off-by: Tamas K Lengyel
---
xen/common/mem_event.c | 4
xen/include/asm-x86/p2m.h | 8 +---
xen/include/public/domctl.h | 1 -
3 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/
To avoid growing hvm.c these functions can be stored
separately.
Signed-off-by: Tamas K Lengyel
---
v3: Style fixes and removing unused fields from msr events.
---
xen/arch/x86/hvm/Makefile | 3 +-
xen/arch/x86/hvm/event.c| 203
xen/arch/x
From: Razvan Cojocaru
The public mem_event structures used to communicate with helper applications via
shared rings have been used in different settings. However, the variable names
within this structure have not reflected this fact, resulting in the reuse of
variables to mean different things un
This patch series aims to clean up the mem_event subsystem within Xen. The
original use-case for this system was to allow external helper applications
running in privileged domains to control various memory operations performed
by Xen. Amongs these were paging, sharing and access control. The subsy
The only use-case of the mem_event_op structure had been in mem_paging,
thus renaming the structure mem_paging_op and relocating its associated
functions clarifies its actual usage.
Signed-off-by: Tamas K Lengyel
Acked-by: Tim Deegan
---
v3: Style fixes
---
tools/libxc/xc_mem_event.c | 16
[Added Michal. Removed Yann.]
On Thu, 2015-01-29 at 12:38 -0800, Luis R. Rodriguez wrote:
> On Tue, Jan 27, 2015 at 12:00 PM, Luis R. Rodriguez wrote:
> > On Fri, Jan 23, 2015 at 03:19:25PM +, Stefano Stabellini wrote:
> >> On Fri, 23 Jan 2015, Luis R. Rodriguez wrote:
> >> > On Wed, Jan 14,
On Tue, Jan 27, 2015 at 12:00 PM, Luis R. Rodriguez wrote:
> On Fri, Jan 23, 2015 at 03:19:25PM +, Stefano Stabellini wrote:
>> On Fri, 23 Jan 2015, Luis R. Rodriguez wrote:
>> > On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote:
>> > > From: "Luis R. Rodriguez"
>> > >
>> > >
On Thu, Jan 29, 2015 at 06:01:36PM +, David Vrabel wrote:
> On 29/01/15 13:36, Ian Campbell wrote:
> > On Mon, 2014-09-01 at 18:52 +0100, David Vrabel wrote:
> >> If the balloon driver is adding additional memory regions to the
> >> balloon and add_memory() fails it will likely continuously fai
On Tue, Jan 27, 2015 at 10:06:44AM +, David Vrabel wrote:
> On 27/01/15 08:35, Jan Beulich wrote:
> On 27.01.15 at 02:51, wrote:
> >
> > Even if David told you this would be acceptable, I have to question
> > an abstract model of fixing issues on only 64-bit kernels - this may
> > be acc
flight 33874 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33874/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-armhf-armhf-libvirt 9 guest-start
On Thu, Jan 29, 2015 at 06:34:23PM +, Andrew Cooper wrote:
>
> Getting this conversation back on topic.
>
> The current state of play in Xen is this:
>
> * Boot time microcode loading exists (by scanning uncompressed cpio
> multiboot modules) and should be safe to use.
Please note that it d
flight 33872 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33872/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 5 xen-boot fail REGR. vs. 26303
test-amd64-i386-xl-qem
>> On 01/29/15 07:09, Paul Durrant wrote:
...
>> Given that IIRC you are using a new dedicated IOREQ type, I
>> think there needs to be something that allows an emulator to
>> register for this IOREQ type. How about adding a new type to
>> those defined for HVMOP_map_io_range_to_ioreq_server for yo
On Thu, Jan 29, 2015 at 04:21:05AM +0100, Luis R. Rodriguez wrote:
> How close?
As close as we can get but not closer - see the thing about updating
microcode on Intel hyperthreaded logical cores in the other mail.
We probably can do it in parallel if needed. But it hasn't been needed
until now.
Hi Andrew,
On 28/01/15 15:52, Andrew Cooper wrote:
> c/s 5b5c40c0d1 "libxc: introduce a per architecture scratch pfn for temporary
> grant mapping" accidentally an issue whereby there were two paths out of
> xc_core_arch_get_scratch_gpfn() which returned 0, but only one of which
> assigned a value
Hello,
Ping? Any more review for this version of this series?
Regards,
On 16/01/15 16:20, Julien Grall wrote:
> Hello,
>
> This small series add/remove __init on different functions. This allow Xen to
> free around 8Kb more of memory after it has finished to boot.
>
> Xen size in memory before
Getting this conversation back on topic.
The current state of play in Xen is this:
* Boot time microcode loading exists (by scanning uncompressed cpio
multiboot modules) and should be safe to use.
* The facility for runtime microcode loading exists (via privileged
hypercall), but is unsafe to u
On 01/29/2015 10:39 AM, Jan Beulich wrote:
Linux is in the process of converting their seconds representation to
64 bits, so in order to support it consistently we should follow suit
(which at some point in quite a few years we'd have to do anyway). To
represent this in struct shared_info we leve
Signed-off-by: Julien Grall
---
This patch is candidate for backporting to Xen 4.4 and Xen 4.5.
Although, this patch won't apply directly to Xen 4.4.
Changes in v2:
- Patch added
---
xen/arch/arm/vgic-v2.c | 18 +-
1 file changed, 9 insertions(+), 9 deletion
There is a one-to-one mapping between each re-distributors and processors.
Each re-distributors can be accessed by any processor at any time. For
instance during the initialization of the GIC, the drivers will browse
the re-distributor to find the one associated to the current processor
(via GICR_T
- Drop wrong comment about the default stride. It's not always 2 * SZ_64K
- Explain why SZ_64K * 2
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/gic-v3.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/xen/arch/arm/gic-v3
The 32-bit register GICR_NSACR is RAZ/WI on non-secure state. Therefore
we should not inject a data abort to the guest.
Signed-off-by: Julien Grall
---
This patch should be backport to Xen 4.5. The current implementation will
inject a data abort into the guest.
Changes in v2:
Some of the registers are accessible via multiple size (see GICD_IPRIORITYR*).
Thoses registers are misimplemented when they should be RAZ. Only
word-access size are currently allowed for them.
To avoid further issues, introduce different label following the access-size
of the registers:
- re
Also update the different comment to make clear that we register one MMIO
region per contiguous regions and not per re-distributor.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/gic-v3.c| 20 ++--
xen/arch/arm/vgic-v3.c |
The stride may not be set if the hardware GIC is using the default
layout. It happens on the Foundation model.
On GICv3, the default stride is 2 * 64K. Therefore it's possible to avoid
checking at every redistributor MMIO access if the stride is not set.
This is only happening for DOM0, so we can
Hello,
The first goal of this series is to fix Linux 3.19 DOM0 boot on GICv3 systems
(see patch #1).
It turns out to a bigger series because there were some outstanding bugs in the
vGIC emulation. The most important one is the way we emulate the re-distributor.
Each re-distributor should be assoc
On GICv3, the value (CPUNumber + 1) indicates the number of processor that may
be used as interrupts targets when ARE bit is zero. The maximum is 8
processors.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
The current code of the vGIC doesn't support ARE = 0.
Nonetheless, the pa
This register is shared between every vCPUs and the lock was already
taken for read.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
This patch should be backported to Xen 4.4 and Xen 4.5.
Although, it won't apply directly for Xen 4.4.
Changes in v2:
- Add Ian's ack
The number of implemented CPU interfaces is one more than the value of
this field.
Also avoid hardcoding the shift and remove useless mask.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
This patch should be backported to Xen 4.4 and Xen 4.5.
Although this patch won't apply di
The messages in the common emulation doesn't specify which distributor
(redistributor or distributor) is used. This make difficult to find the
correct registers.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/vgic-v3.c | 35 ++--
>From Linux 3.19, the GICv3 drivers is using GICD_TYPER.IDbits to check
the validity of the hardware interrupt number.
The field IDBits in the register GICD_TYPER is used to know the number of
interrupt identifiers (SPI, PPIs, SGIs, LPIs) supported by GIC Stream Protocol
Interface.
This field con
The current VGIC code doesn't support to change the pending and active status
of an IRQ via the (re-)distributor.
If we plan to support it in the future, it will unlikely require a specific
bitfield as we already store the status per vIRQ.
Rather than wasting memory for nothing, drop thoses field.
Some of the registers are accessible via multiple size (see GICD_IPRIORITYR*).
Thoses registers are misimplemented when they should be RAZ. Only
word-access size are currently allowed for them.
To avoid further issues, introduce different label following the access-size
of the registers:
- re
As backward GICv2 compatibility is not supported in the vGICv3 driver,
the bit ARE_NS is RAO/WI.
Furthermore, when ARE_NS is set, the guest can only modify EnableGrp1A.
At same time take the vgic_lock to write into domain.arch.vgic.ctrl. It
was already taken during read.
Signed-off-by: Julien Gr
Don't have the hypervisor update APIC_LVTPC when _it_ thinks the vector
should be updated. Instead, handle guest's APIC_LVTPC accesses and write what
the guest explicitly wanted (but only when VPMU is enabled).
This is updated version of commit 8097616fbdda that was reverted by
cc3404093c85. Unlik
NMI watchdog sets APIC_LVTPC register to generate an NMI when PMU counter
overflow occurs. This may be overwritten by VPMU code later, effectively
turning off the watchdog.
We should disable VPMU when NMI watchdog is running.
Signed-off-by: Boris Ostrovsky
---
docs/misc/xen-command-line.markdow
Use NMI_NONE when testing whether NMI watchdog is off.
Remove unused NMI_INVALID macro.
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/nmi.c | 4 ++--
xen/arch/x86/traps.c | 3 ++-
xen/include/asm-x86/apic.h | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/xe
Changes in v2:
* Added NMI cleanup patch
* Disaple VPMU in vpmu_initialise() instead of doing it in options parsing
routines
* Update documentation by mentioning that VPMU doesn't work with watchdog
* Drop some sign-off area tags
The first patch is a light cleanup of nmi_watchdog usage. (I remov
flight 33862 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33862/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-credit25 xen-boot fail REGR. vs. 33637
Regressions which ar
On 29/01/15 13:36, Ian Campbell wrote:
> On Mon, 2014-09-01 at 18:52 +0100, David Vrabel wrote:
>> If the balloon driver is adding additional memory regions to the
>> balloon and add_memory() fails it will likely continuously fail so
>> cancel the balloon operation.
>>
>> Signed-off-by: David Vrabe
On Thu, Jan 29, 2015 at 11:10:39AM +, Ian Campbell wrote:
> On Wed, 2015-01-28 at 22:52 +, Wei Liu wrote:
> > > guests, is preballooning allowed there too?
> >
> > I need to check PV boot sequence to have a definite answer.
> >
> > Currently memory allocation in libxc only deals with a ch
At 15:39 + on 29 Jan (1422542343), Jan Beulich wrote:
> Linux is in the process of converting their seconds representation to
> 64 bits, so in order to support it consistently we should follow suit
> (which at some point in quite a few years we'd have to do anyway). To
> represent this in struc
At 11:10 + on 28 Jan (1422439811), Andrew Cooper wrote:
> On 28/01/15 08:11, Jan Beulich wrote:
> > Considering the complexity of the code, it seems to be a reasonable
> > thing to allow people to disable that code entirely even outside the
> > immediate need for this by the next patch.
> >
> >
On Thu, 29 Jan 2015, Xu, Quan wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> > Sent: Tuesday, January 20, 2015 1:15 AM
> > To: Xu, Quan
> > Cc: qemu-de...@nongnu.org; xen-devel@lists.xen.org;
> > stefano.stabell...@eu.citrix.com
> > Su
Hi,
At 11:50 +0100 on 27 Jan (1422355826), Tim Deegan wrote:
> Let me have a think about it on Thursday (assuming I don't have too
> many patch series to review by then!)
OK, here's what I have. It keeps the mechanism the same, threading on
the main page list entry, but tidies it up to use the
On Thu, Jan 29, 2015 at 03:01:22PM -0200, Henrique de Moraes Holschuh wrote:
> No, I have not. It was a direct observation based on the fact that
> there is a report of a system misbehaving because of mismatched AMD
> microcode in this very thread. Now, if someone from AMD did state that
> they a
On Tue, Jan 27, 2015 at 6:49 AM, Ian Jackson wrote:
> We are splitting minios out of xen.git (because we want to try to make
> it easier to un-fork it - there are about 3-4 forks that we are aware
> of).
>
> We think it should have its own mailing list. I propose
> "minios-de...@lists.xenproject.
On Thu, Jan 29, 2015, at 10:17, Borislav Petkov wrote:
> On Thu, Jan 29, 2015 at 09:36:49AM -0200, Henrique de Moraes Holschuh
> wrote:
> > But the fact that you cannot trust a system with mismatched microcode to
> > be stable is the hard truth: neither AMD nor Intel are really enforcing
> > that l
On Mon, 2015-01-26 at 11:25 +0800, Chunyan Liu wrote:
> Changes to V9:
> * update libxl_disk_snapshot structures as Ian suggests
> * add more descriptions for libxl_disk_snapshot_delete
> * add two functions for deleting external disk snapshot:
> libxl_domain_block_rebase and libxl_domain
On Mon, 2015-01-26 at 11:25 +0800, Chunyan Liu wrote:
> Changes to V9:
This looks good to me, thanks.
Ian/Wei do you have any comments? xapi folks?
> - add details and background knowledge in overview (2/4).
> - update xl snapshot-create syntax and cfg syntax (3/4)
> - update libxl_disk_sn
On Mon, 2015-01-26 at 11:25 +0800, Chunyan Liu wrote:
This is all looking good (including the previous two patches where I
didn't have any substantial comments).
> User could specify snapshot information in details through @cfgfile, see
> following cfgfile syntax. If configuration in @cfg
flight 33850 xen-4.5-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33850/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass
test-armhf-armhf-libvirt 9 gue
On Thu, Jan 29, 2015 at 11:04:15AM +, Ian Campbell wrote:
> On Wed, 2015-01-28 at 21:51 +, Wei Liu wrote:
> > On Wed, Jan 28, 2015 at 04:13:28PM +, Ian Campbell wrote:
> > > On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> > > > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl
> -Original Message-
> From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> Sent: Tuesday, January 20, 2015 1:15 AM
> To: Xu, Quan
> Cc: qemu-de...@nongnu.org; xen-devel@lists.xen.org;
> stefano.stabell...@eu.citrix.com
> Subject: Re: [v3 2/5] Qemu-Xen-vTPM: Xen frontend d
On Thu, Jan 29, 2015 at 11:06:07AM +, Ian Campbell wrote:
> On Wed, 2015-01-28 at 22:22 +, Wei Liu wrote:
> > On Wed, Jan 28, 2015 at 04:41:11PM +, Ian Campbell wrote:
> > > On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> > > > Disallow memory relocation when vNUMA is enabled, becau
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 doesn't know which vIRQ will be free.
All the vIRQ will be reserved when we parse the device tree. So we can
allocate the vIRQ just after the device tree has been pars
While it's easy to know which hardware IRQ is assigned to a domain, there
is no way to know which vIRQ is allocated 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
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 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 and ass
On Tue, Jan 27, 2015 at 02:19:23PM +, Anil Madhavapeddy wrote:
[...]
> >
>
> That makes reconciling some of these long running forks annoying,
> since they branched off xen.git. It doesn't matter if you split/fix
> in any order, but it's nice to have one changeset against xen.git that
> brea
>>> On 29.01.15 at 16:28, wrote:
> However, if you insist on dropping all tags even for minor changes like
> that (and "determining what "minor" is is a judgment call) I will
> certainly do that in the future.
I don't mind you (and others) keeping them for minor changes. But a
small change isn'
Linux is in the process of converting their seconds representation to
64 bits, so in order to support it consistently we should follow suit
(which at some point in quite a few years we'd have to do anyway). To
represent this in struct shared_info we leverage a 32-bit hole in
x86-64's and arm's vari
Hello,
El 29/01/15 a les 13.44, Yuzhou (C) ha escrit:
> Hi Roger,
>
>> Yes, I've successfully tested Xen 4.5.0 and Linux 3.18.0.
>
>
> Did you do any patch?
Well, as said before PVH Dom0 is still very experimental. I usually find
issues as I test it on different hardware. Right now I've
On 01/29/2015 06:54 AM, Jan Beulich wrote:
On 28.01.15 at 20:56, wrote:
Don't have the hypervisor update APIC_LVTPC when _it_ thinks the vector
should be updated. Instead, handle guest's APIC_LVTPC accesses and write
what
the guest explicitly wanted (but only when VPMU is enabled).
This is upd
On 01/29/2015 06:46 AM, Jan Beulich wrote:
On 28.01.15 at 20:56, wrote:
@@ -59,6 +60,12 @@ static void __init parse_vpmu_param(char *s)
}
/* fall through */
case 1:
+if ( opt_watchdog )
+{
+printk("NMI watchdog is enabled. Disabling VPMU\n")
On 29/01/15 15:03, Stefano Stabellini wrote:
> On Thu, 29 Jan 2015, Julien Grall wrote:
>> On 29/01/15 12:09, Stefano Stabellini wrote:
>>> On Thu, 29 Jan 2015, Julien Grall wrote:
Hi Stefano,
On 29/01/15 10:29, Stefano Stabellini wrote:
>> +static bool_t iommu_dt_device_is_assig
When resource assignment fails, things may end up this way, and we want
to avoid using the resource in that case.
Derived from an upstream patch by Yijing Wang .
Signed-off-by: Jan Beulich
--- a/drivers/pci/msi-xen.c
+++ b/drivers/pci/msi-xen.c
@@ -204,7 +204,9 @@ static u64 find_table_base(str
On 29/01/15 15:04, Stefano Stabellini wrote:
> On Thu, 29 Jan 2015, Julien Grall wrote:
>> On 29/01/15 12:28, Stefano Stabellini wrote:
>>> On Thu, 29 Jan 2015, Julien Grall wrote:
On 29/01/15 11:07, Stefano Stabellini wrote:
> On Tue, 13 Jan 2015, Julien Grall wrote:
>> The partial de
In libxl_set_memory_target when setting the new maxmem, retain the same
offset on top of the current target. In the future the offset will
include memory allocated by QEMU for rom files.
Given that LIBXL_MAXMEM_CONSTANT is already added to maxmem at VM
creation time, we don't need to add it again
1 - 100 of 209 matches
Mail list logo
