>>> On 20.09.17 at 23:47, wrote:
> On Ma, 2017-09-19 at 09:19 -0600, Jan Beulich wrote:
>> > > > On 12.09.17 at 16:32, wrote:
>> > @@ -2102,6 +2112,7 @@ void hvm_emulate_one_vm_event(enum emul_kind
>> > kind, unsigned int trapnr,
>> > * consistent with X86EMUL_RETRY.
>> > */
>
>>> On 21.09.17 at 03:12, wrote:
> On Fri, 1 Sep 2017, Jan Beulich wrote:
>> --- a/hw/xen/xen_pt_msi.c
>> +++ b/hw/xen/xen_pt_msi.c
>> @@ -18,6 +18,11 @@
>>
>> #define XEN_PT_AUTO_ASSIGN -1
>>
>> +#ifndef XEN_DOMCTL_VMSI_X86_DEST_ID_MASK
>> +#if XEN_DOMCTL_INTERFACE_VERSION >= 0x000e
>> +
>>> On 21.09.17 at 06:27, wrote:
> IMHO it would be better to add:
>
> static int __init grant_table_init_dom0()
>
> hiding the two variables. This makes it more obvious that path is taken
> only at boot time.
Oh, that's fine of course, and hence appreciated (but it obviously
won't make the ini
>>> On 21.09.17 at 06:35, wrote:
> On 20/09/17 17:35, Jan Beulich wrote:
> On 20.09.17 at 14:44, wrote:
>>> On 20/09/17 13:48, Jan Beulich wrote:
>>> On 20.09.17 at 13:10, wrote:
> I thought about a cap and TBH I'm not sure which would be sane to
> apply. The global limits seem w
flight 113647 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113647/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 947f3737abf65fda63f3ffd97fddfa6986986868
baseline version:
ovmf b68c793144e8f239cf59f
Hi Sameer,
On 9/21/2017 6:07 AM, Sameer Goel wrote:
This change incoporates most of the review comments from [1] and adds the
proposed SMMUv3 driver.
List of changes:
- Introduce the iommu_fwspec implementation - No change from the last RFC
- IORT port from linux. The differences are as under:
Modified the behavior of hvm_emulate_one_insn and
vmx_realmode_emulate_one to generate an Invalid Opcode trap when
X86EMUL_UNRECOGNIZED is returned by the emulator instead of just
crashing the domain.
Signed-off-by: Petre Pircalabu
Reviewed-by: Kevin Tian
---
xen/arch/x86/hvm/io.c |
Enforce the distinction between an instruction not implemented by the
emulator and the failure to emulate that instruction by defining a new
return code, X86EMUL_UNIMPLEMENTED.
This value should only be returned by the core emulator only if it fails to
properly decode the current instruction's opc
This patchset implements a mechanism which allows XEN to send first an event
if the emulator encountered an unsupported instruction.
The monitor application can choose to mitigate the error, for example to
singlestep
the instruction using the real processor and then resume execution of the normal
If case of a vm_event with the emulate_flags set, if the instruction
is not implemented by the emulator, the monitor should be notified instead
of directly injecting a hw exception.
This behavior can be used to re-execute an instruction not supported by
the emulator using the real processor (e.g. a
- print the return code of the last failed emulator operation
in hvm_dump_emulation_state.
- print the return code in sh_page_fault (SHADOW_PRINTK) to make the
distiction between X86EMUL_UNHANDLEABLE and X86EMUL_UNIMPLEMENTED.
Signed-off-by: Petre Pircalabu
Reviewed-by: Jan Beulich
---
Changed
This run is configured for baseline tests only.
flight 72133 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72133/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win10-i386 16 guest-
On 20/09/17 16:34, Julien Grall wrote:
> Hi Juergen,
>
> On 20/09/17 07:34, Juergen Gross wrote:
>> diff --git a/xen/include/asm-arm/grant_table.h
>> b/xen/include/asm-arm/grant_table.h
>> index 0a248a765a..0870b5b782 100644
>> --- a/xen/include/asm-arm/grant_table.h
>> +++ b/xen/include/asm-arm/g
On 20/09/17 17:35, Jan Beulich wrote:
On 20.09.17 at 14:44, wrote:
>> On 20/09/17 13:48, Jan Beulich wrote:
>> On 20.09.17 at 13:10, wrote:
On 20/09/17 12:34, Jan Beulich wrote:
On 20.09.17 at 08:34, wrote:
>> --- a/xen/common/compat/grant_table.c
>> +++ b/xen/comm
On 20/09/17 17:36, Jan Beulich wrote:
On 20.09.17 at 14:48, wrote:
>> On 20/09/17 14:07, Jan Beulich wrote:
>> On 20.09.17 at 08:34, wrote:
@@ -3469,14 +3460,17 @@ grant_table_create(
/* Simple stuff. */
percpu_rwlock_resource_init(&t->lock, grant_rwlock);
On 20/09/17 17:42, Jan Beulich wrote:
On 20.09.17 at 14:58, wrote:
>> On 20/09/17 14:18, Jan Beulich wrote:
>> On 20.09.17 at 08:34, wrote:
On very large hosts a guest needs to know whether it will have to
>>>
>>> ... a PV guest ...
>>
>> What about a HVM guest with (potentially) mo
On 20/09/17 19:15, Julien Grall wrote:
> Hi Juergen,
>
> On 20/09/17 15:33, Juergen Gross wrote:
>> On 20/09/17 16:24, Julien Grall wrote:
>>> On 20/09/17 14:08, Juergen Gross wrote:
On 20/09/17 14:51, Julien Grall wrote:
> Hi Juergen,
>
> Sorry for the late comment.
>
> O
From: Roger Pau Monne
When a MSI interrupt is bound to a guest using
xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
left masked by default.
This causes problems with guests that first configure interrupts and
clean the per-entry MSIX table mask bit and afterwards enable MSIX
From: Olaf Hering
g_malloc0_n is available since glib-2.24. To allow build with older glib
versions use the generic g_new0, which is already used in many other
places in the code.
Fixes commit 3284fad728 ("xen-disk: add support for multi-page shared rings")
Signed-off-by: Olaf Hering
Reviewed-
t tags/xen-20170920-tag
for you to fetch changes up to a8036336609d2e184fc3543a4c439c0ba7d7f3a2:
xen/pt: allow QEMU to request MSI unmasking at bind time (2017-09-20 19:05:27
-0700)
Xen
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Wednesday, August 30, 2017 6:35 PM
>
> The new function is responsible for handling WRMSR from both HVM and
> PV
> guests. Currently it handles only 2 MSRs:
>
> MSR_INTEL_PLATFORM_INFO
> MSR_INTEL_MISC_FEATURES_ENABLES
>
> I
flight 113629 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113629/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-vhd 6 xen-install fail in 113615 pass in 113629
test-amd64-i386-rumprun-i386 17 r
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Wednesday, August 30, 2017 6:35 PM
>
> The new function is responsible for handling RDMSR from both HVM and
> PV
> guests. Currently it handles only 2 MSRs:
>
> MSR_INTEL_PLATFORM_INFO
> MSR_INTEL_MISC_FEATURES_ENABLES
>
> I
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Wednesday, August 30, 2017 6:35 PM
>
> Since each vCPU now has struct msr_vcpu_policy, use cpuid_faulting bit
> from there in current logic and remove arch_vcpu::cpuid_faulting.
>
> Signed-off-by: Sergey Dyasli
Reviewed-by: Kevin T
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Wednesday, August 30, 2017 6:35 PM
>
> The new structure contains information about guest's MSRs that are
> unique to each vCPU. It starts with only 1 MSR:
>
> MSR_INTEL_MISC_FEATURES_ENABLES
>
> Which currently has only 1 usabl
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Wednesday, August 30, 2017 6:34 PM
>
> The new structure contains information about guest's MSRs that are
> shared between all domain's vCPUs. It starts with only 1 MSR:
>
> MSR_INTEL_PLATFORM_INFO
>
> Which currently has only 1
On 9/12/2017 11:10 AM, Jan Beulich wrote:
> By virtue of the struct xen_sysctl container structure, most of them
> are really just cluttering the name space.
>
> Signed-off-by: Jan Beulich
>
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1212,11 +1212,11 @@ i
On 9/20/2017 6:41 AM, George Dunlap wrote:
> On Tue, Sep 12, 2017 at 4:10 PM, Jan Beulich wrote:
>> By virtue of the struct xen_sysctl container structure, most of them
>> are really just cluttering the name space.
>>
>> Signed-off-by: Jan Beulich
>
> Acked-by: George Dunlap
>
>>
>> --- a/xe
On Fri, 1 Sep 2017, Jan Beulich wrote:
> Xen and qemu having identical #define-s (with different names) is a
> strong hint that these should have been part of the public interface
> from the very start. Use them if they're available, falling back to
> privately defined values only when using older
Introduce a common structure to hold the fw (ACPI or DT) defined
configuration for SMMU hw. The current use case is for arm SMMUs. So,
making this architecture specific.
Based on Linux kernel commit 57f98d2f61e1: iommu: Introduce iommu_fwspec
Signed-off-by: Sameer Goel
---
xen/drivers/passthroug
On 9/12/2017 5:25 AM, Julien Grall wrote:
> Hi Sameer,
>
> On 28/08/17 23:21, Goel, Sameer wrote:
>> On 6/12/2017 7:24 AM, Julien Grall wrote:
static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
struct fwnode_handle *fwnode,
Based on commit bdf95923086fb359ccb44c815724c3ace1611c90
This is a verbatim snapshot of arm-smmu-v3.c from Linux kernel source
code.
No Xen code has been added and the file is not built.
Signed-off-by: Sameer Goel
---
xen/drivers/passthrough/arm/smmu-v3.c | 2791 +++
This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */
Signed-off-
Modify the SMMU code to use generic device instead of dt_device_node for
functions that can be used for ACPI based systems too.
Signed-off-by: Sameer Goel
---
xen/drivers/passthrough/arm/smmu.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/drivers/passthrou
Add support for parsing IORT table to initialize SMMU devices.
* The code for creating an SMMU device has been modified, so that the SMMU
device can be initialized.
* The NAMED NODE code has been commented out as this will need DOM0 kernel
support.
* ITS code has been included but it has not been t
Verbatim files from Linux kernel.
iort.c: commit d89cf2e41826: ACPI/IORT: Fix the indentation in
iort_scan_node()
acpi_iort.h: commit 18b709beb503:ACPI/IORT: Make dma masks set-up IORT
specific
Signed-off-by: Sameer Goel
---
xen/drivers/acpi/arm/iort.c | 961
This change incoporates most of the review comments from [1] and adds the
proposed SMMUv3 driver.
List of changes:
- Introduce the iommu_fwspec implementation - No change from the last RFC
- IORT port from linux. The differences are as under:
* Modified the code for creating the SMMU devic
This will be used as a device property to match the DMA capable devices
with the associated SMMU. The header file is a port from linux. The code
was changed to remove the types that were not needed for Xen.
Linux ChangeId:ce793486e23e: driver core / ACPI: Represent ACPI
companions using fwnode_han
In commit ad4b3e1e9df34 ("xen: credit2: implement
utilization cap") xfree() was being called (for
deallocating the budget replenishment timer, during
domain destruction) inside an IRQ disabled critical
section.
That must not happen, as it uses the mem-pool's lock,
which needs to be taken with IRQ
On Wed, 2017-09-20 at 14:49 +0100, George Dunlap wrote:
> On 09/20/2017 12:59 PM, Jan Beulich wrote:
> > Hmm, killing the timer upfront is certainly fine, but is freeing
> > the
> > data before removing the element from the list safe not only
> > currently, but also going forward?
>
> I agree with
flight 113643 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113643/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
This run is configured for baseline tests only.
flight 72132 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72132/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b68c793144e8f239cf59fcc34ee6e35c1fdcd8a6
baseline v
The ELF specification mentions nothing about the sh_size being
modulo the sh_addralign. Only that sh_addr MUST be aligned on
sh_addralign if sh_addralign is not zero or one.
We on loading did not take this in-to account so this patch adds
a check on the ELF file as it is being parsed.
Reviewed-by
By default when using objcopy we lose the alignment when we copy it from
xen-syms -
with the result that alignment (on ARM32 for example) can be 1:
[Nr] Name TypeAddr OffSize ES Flg Lk Inf Al
..
[ 6] .livepatch.depend PROGBITS 93 24 0
From: Ross Lagerwall
See docs/features/livepatch.pandoc for the details.
Reviewed-by: Jan Beulich
Signed-off-by: Ross Lagerwall
Signed-off-by: Konrad Rzeszutek Wilk
--
v2:
- Moved it into a feature document.
- Clarified a few bits and pieces based on feedback.
v3:
- default X86
- added J
This was found when porting livepatch-build-tools to ARM64/32
When livepatch-build-tools are built (and test-case thanks to:
livepatch/tests: Make sure all .livepatch.funcs sections are read-only)
the .livepatch.funcs are in read-only section.
However the hypervisor uses the 'opaque' for its own
It makes more sense to put a tool to be used by other subsystems
to be in 'tools/misc' along 'mkrpm','mkdeb', etc.
The patch titled "xen/livepatch/x86/arm32: Force .livepatch.depends
section to be uint32_t aligned" uses mkhex.
Suggested-by: Julien Grall
Signed-off-by: Konrad Rzeszutek Wilk
---
If the livepatch has only .rodata sections then it is OK to also
apply/revert/apply the livepatch without having to worry about the
unforseen consequences.
See commit 98b728a7b235c67e210f67f789db5d9eb38ca00c
"livepatch: Disallow applying after an revert" for details.
Signed-off-by: Konrad Rzeszut
This is very similar to 137c59b9ff3f7a214f03b52d9c00a0a02374af1f
"bug/x86/arm: Align bug_frames sections."
On ARM and on x86 the C and assembler macros don't include
any alignment information - hence they end up being the default
byte granularity.
On ARM32 it is paramount that the alignment is wo
Instead of being writable (.data). This mimics the behavior of what
livepatch-build-tools do.
Other approaches such as 'struct const livepatch_funcs' still result
in the WA section attributes.
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Ross Lagerwall
v2: First posting.
v3: Don't do multiple
Hey,
As I was trying to port livepatch-build-tools.git to work under ARM32 and ARM64
(still ongoing, if somebody wants to help/take over would appreciate it)
I found some inconsistencies compared to the x86 and test-cases:
- The .livepatch.funcs in the test-cases are in RW section but the
livep
This surfaced due to "xen/livepatch/x86/arm32: Force
.livepatch.depends section to be uint32_t aligned." which switched
to a different way of including the build-id.
Each livepatch ends with a global:
30: 1 OBJECT GLOBAL HIDDEN 7 note_depends
which will cause collision when
If the .bug.frames.X or .livepatch.funcs sizes are different
than what the hypervisor expects - we fail the payload. To help
in diagnosing this include the expected and the payload
sizes.
Also make it more natural by having "Multiples" in the warning.
Also fix one case where we would fail if the
The ARM 32&64 ELF specification says "sections containing ARM
code must be at least 32-bit aligned." This patch adds the
check for that. We also make sure that this check is done
when doing relocations for the types that are considered
ARM code. However we don't have to check for all as we only
imp
On 20/09/2017 22:07, Stefano Stabellini wrote:
On Wed, 20 Sep 2017, Julien Grall wrote:
Hi,
On 20/09/17 00:59, Stefano Stabellini wrote:
On Tue, 12 Sep 2017, Julien Grall wrote:
Currently, it is not possible to specify the permission of a new
mapping. It would be necessary to use the functi
Hi Stefano,
On 20/09/2017 22:03, Stefano Stabellini wrote:
On Wed, 20 Sep 2017, Julien Grall wrote:
Hi,
On 20/09/17 00:51, Stefano Stabellini wrote:
On Tue, 12 Sep 2017, Julien Grall wrote:
Currently MAIRVAL is defined in term of MAIR0VAL and MAIR1VAL which are
both hardcoded value. This mak
flight 113626 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113626/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 6 xen-install fail in 113613 pass in 113626
test-amd64-i386-xl-qemuu-win7-a
On Ma, 2017-09-19 at 09:19 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 12.09.17 at 16:32, wrote:
> > Enforce the distinction between an instruction not implemented by
> > the
> > emulator and the failure to emulate that instruction by defining a
> > new
> > return code, X86EMUL_UNIMPLEM
flight 113636 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113636/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b68c793144e8f239cf59fcc34ee6e35c1fdcd8a6
baseline version:
ovmf 70dc3ec5a72e0e3fc3ea8
On 18/09/2017, 05:17, "Felipe Huici" wrote:
Hi Lars, all,
[cc’ing authors of Erlang on Xen, HalVM and Rump].
Thanks everyone for all of the support and useful comments. We’ve
incorporated a number of them into a new version of the document (attached
and pasted at t
On Wed, Sep 20, 2017 at 03:01:57PM +0100, Wei Liu wrote:
> On Tue, Sep 19, 2017 at 12:05:16PM +0100, Julien Grall wrote:
> > Hi Konrad,
> >
> > On 19/09/17 01:32, Konrad Rzeszutek Wilk wrote:
> > > > > +.PHONY: livepatch_depends.h
> > > > > +livepatch_depends.h: note.bin
> > > > > + $(shell (.
On Tue, 19 Sep 2017, Stefano Stabellini wrote:
> On Tue, 12 Sep 2017, Julien Grall wrote:
> > Hi all,
> >
> > This patch series contains clean-up for the ARM memory subsystem in
> > preparation
> > of reworking the page tables handling.
> >
> > A branch with the patches can be found on xenbits:
On 09/15/2017 07:00 PM, Stefano Stabellini wrote:
> Implement the probe function for the pvcalls frontend. Read the
> supported versions, max-page-order and function-calls nodes from
> xenstore.
>
> Only one frontend<->backend connection is supported at any given time
> for a guest. Store the activ
On Wed, 20 Sep 2017, Julien Grall wrote:
> Hi,
>
> On 20/09/17 00:59, Stefano Stabellini wrote:
> > On Tue, 12 Sep 2017, Julien Grall wrote:
> > > Currently, it is not possible to specify the permission of a new
> > > mapping. It would be necessary to use the function modify_xen_mappings
> > > wit
On Wed, 20 Sep 2017, Julien Grall wrote:
> Hi,
>
> On 20/09/17 00:51, Stefano Stabellini wrote:
> > On Tue, 12 Sep 2017, Julien Grall wrote:
> > > Currently MAIRVAL is defined in term of MAIR0VAL and MAIR1VAL which are
> > > both hardcoded value. This makes quite difficult to understand the value
>
> static int pvcalls_front_remove(struct xenbus_device *dev)
> {
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map = NULL, *n;
> +
> + bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
> + dev_set_drvdata(&dev->dev, NULL);
> + pvcalls_front_dev = NULL;
One
From: Tamas K Lengyel
The EFI messages flash by so fast that it is impossible to catch them without
a serial debugger attached. Sometimes though we don't have that available so
having some time to read the messages off the screen is valuable.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
---
From: Tamas K Lengyel
If the shim protocol is located it is expected that the dom0 kernel image
will also pass the shim verification.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
---
xen/common/efi/boot.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/xen/com
flight 113624 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113624/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs.
113605
test-armhf-armhf-
> +
> +struct pvcalls_bedata {
> + struct xen_pvcalls_front_ring ring;
> + grant_ref_t ref;
> + int irq;
> +
> + struct list_head socket_mappings;
> + struct list_head socketpass_mappings;
> + spinlock_t socket_lock;
> +
> + wait_queue_head_t inflight_req;
> + struc
On 20.09.17 23:02, Julien Grall wrote:
On 20/09/2017 19:11, Volodymyr Babchuk wrote:
On 20.09.17 20:21, Julien Grall wrote:
On 19/09/17 22:44, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
On 13.09.17 14:11, Julien Grall wrote:
Hi,
On 08/31/2017 09:09 PM, Volodymyr Babchuk wro
On 20/09/2017 19:11, Volodymyr Babchuk wrote:
On 20.09.17 20:21, Julien Grall wrote:
On 19/09/17 22:44, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
On 13.09.17 14:11, Julien Grall wrote:
Hi,
On 08/31/2017 09:09 PM, Volodymyr Babchuk wrote:
+static void fill_uuid(struct cpu_u
Hi Xen-devel,
I'm using PCI pass-through to map a PCIe (intel i210) controller into
a HVM domain. The system uses xen-pciback to hide the appropriate PCI
device from Dom0.
When creating the HVM domain after an hypervisor cold boot, the HVM
domain can access and use the PCIe controller withou
It's a leftover from PVHv1 days.
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/hvm/vmx/vmcs.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index f62fe7e..b5100b5 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
Hi, Kevin
On Wed, Sep 20, 2017 at 11:54 AM, Tian, Kevin wrote:
> this patch alone looks OK to me. but I haven't found time to review
> the whole series to judge whether below change is necessary.
Let me explain.
Here [1] I touched common IOMMU code, and as the result I had to
modify all existin
Hi Julien,
On 20.09.17 20:21, Julien Grall wrote:
>
>
> On 19/09/17 22:44, Volodymyr Babchuk wrote:
>> Hi Julien,
>
> Hi Volodymyr,
>
>>
>> On 13.09.17 14:11, Julien Grall wrote:
>>> Hi,
>>>
>>> On 08/31/2017 09:09 PM, Volodymyr Babchuk wrote:
>>
+static void fill_uuid(struct cpu_user_regs *
Hi,
On 20/09/17 00:59, Stefano Stabellini wrote:
On Tue, 12 Sep 2017, Julien Grall wrote:
Currently, it is not possible to specify the permission of a new
mapping. It would be necessary to use the function modify_xen_mappings
with a different set of flags.
Introduce a couple of new flags for t
Hi,
On 20/09/17 00:51, Stefano Stabellini wrote:
On Tue, 12 Sep 2017, Julien Grall wrote:
Currently MAIRVAL is defined in term of MAIR0VAL and MAIR1VAL which are
both hardcoded value. This makes quite difficult to understand the value
written in both registers.
Rework the definition by using v
Hi,
On 20/09/17 00:33, Stefano Stabellini wrote:
On Tue, 12 Sep 2017, Julien Grall wrote:
DEV_WC is only used for PAGE_HYPERVISOR_WC and does not bring much
improvement.
Signed-off-by: Julien Grall
Reviewed-by: Andre Przywara
---
Changes in v2:
- Remove DEV_WC from the commen
Hi,
On 20/09/17 00:32, Stefano Stabellini wrote:
On Tue, 12 Sep 2017, Julien Grall wrote:
They were imported from non-LPAE Linux, but Xen is LPAE only. It is time
to do some clean-up in the memory attribute and keep only what make
sense for Xen. Follow-up patch will do more clean-up.
Also, upd
flight 113637 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113637/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 19/09/17 22:44, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
On 13.09.17 14:11, Julien Grall wrote:
Hi,
On 08/31/2017 09:09 PM, Volodymyr Babchuk wrote:
+static void fill_uuid(struct cpu_user_regs *regs, const xen_uuid_t *u)
Actually why do you pass a pointer for u? This req
Ping?
On Wed, 6 Sep 2017, Anthony PERARD wrote:
> On Wed, Aug 23, 2017 at 02:25:05PM +0100, Ross Lagerwall wrote:
> > When the guest writes to the RTC, Xen emulates it and broadcasts a
> > TIMEOFFSET ioreq. Emit an RTC_CHANGE QMP event to all QMP monitors when
> > this happens rather than ignoring
This run is configured for baseline tests only.
flight 72131 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72131/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 70dc3ec5a72e0e3fc3ea8f63baecdeafd1110db8
baseline v
Ping?
On Thu, 7 Sep 2017, Anthony PERARD wrote:
> On Mon, Aug 21, 2017 at 04:12:27PM -0700, Stefano Stabellini wrote:
> > Anthony,
> >
> > The code looks good. I tested this patch with Linux guests and seems to
> > work OK, can you also confirm?
>
> I've tested with Linux as well, an HVM guess,
Hi Juergen,
On 20/09/17 15:33, Juergen Gross wrote:
On 20/09/17 16:24, Julien Grall wrote:
On 20/09/17 14:08, Juergen Gross wrote:
On 20/09/17 14:51, Julien Grall wrote:
Hi Juergen,
Sorry for the late comment.
On 20/09/17 07:34, Juergen Gross wrote:
Add a function for obtaining the highest
On 9/15/17 6:35 PM, Dario Faggioli wrote:
static unsigned int __read_mostly opt_migrate_resist = 500;
integer_param("sched_credit2_migrate_resist", opt_migrate_resist);
@@ -1453,6 +1459,26 @@ runq_tickle(const struct scheduler *ops, struct
csched2_vcpu *new, s_time_t now)
On Wed, Sep 20, 2017 at 04:46:16PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v2 02/21] libxl: introduce a way to mark
> fields as deprecated in the idl"):
> > The deprecation involves generating a function that copies the
> > deprecated fields into it's new location if the new lo
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 20 September 2017 13:24
> To: Alexandru Isaila
> Cc: suravee.suthikulpa...@amd.com; Andrew Cooper
> ; Paul Durrant ;
> Wei Liu ; George Dunlap ;
> Ian Jackson ; jun.nakaj...@intel.com; Kevin Tian
> ; sstabell...@ke
flight 113620 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113620/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR.
vs. 113479
test-amd6
On 20/09/17 11:20, Roger Pau Monné wrote:
On Tue, Sep 19, 2017 at 07:06:26PM +0100, Jennifer Herbert wrote:
This Patch allows a migration precopy policy to be specified.
The precopy phase of the xc_domain_save() live migration algorithm has
historically been implemented to run until either a) (
On Thu, Sep 07, 2017 at 11:16:22AM +0100, Roger Pau Monne wrote:
> Those types are missing a helper to check whether a definition of the
> type holds the default value. This will be required by a later patch
> that will implement deprecation of fields inside of a libxl type.
>
> Signed-off-by: Rog
On Wed, Sep 20, 2017 at 09:59:51AM -0600, Tamas K Lengyel wrote:
> On Wed, Sep 20, 2017 at 9:46 AM, Jan Beulich wrote:
> On 20.09.17 at 17:20, wrote:
> >> On Wed, Sep 20, 2017 at 12:30 AM, Jan Beulich wrote:
> >> On 20.09.17 at 00:23, wrote:
> Yeap, the shim pretty simply removed
On Tue, Sep 19, 2017 at 12:30:59PM +0100, Roger Pau Monné wrote:
> > +type = LIBXL_PSR_CBM_TYPE_MBA_THRTL;
> > +
> > +if (libxl_bitmap_is_empty(&target_map))
> > +libxl_bitmap_set_any(&target_map);
> > +
> > +if (argc != optind + 2) {
> > +help("psr-mba-set");
> > +
On Wed, Sep 20, 2017 at 05:22:22PM +0800, Yi Sun wrote:
> On 17-09-20 09:43:40, Roger Pau Monn� wrote:
> > On Wed, Sep 20, 2017 at 01:09:06PM +0800, Yi Sun wrote:
> > > On 17-09-19 10:15:42, Roger Pau Monn� wrote:
> > > > On Tue, Sep 05, 2017 at 05:32:28PM +0800, Yi Sun wrote:
> > > > > diff --git
On Wed, Sep 20, 2017 at 9:46 AM, Jan Beulich wrote:
On 20.09.17 at 17:20, wrote:
>> On Wed, Sep 20, 2017 at 12:30 AM, Jan Beulich wrote:
>> On 20.09.17 at 00:23, wrote:
Yeap, the shim pretty simply removed the .reloc section as it was
marked discardable and did the relocation
>>> On 20.09.17 at 14:54, wrote:
> On Ma, 2017-09-19 at 09:22 -0600, Jan Beulich wrote:
>> > > > On 12.09.17 at 16:32, wrote:
>> > @@ -2242,16 +2242,17 @@ static const char
>> > *guest_x86_mode_to_str(int mode)
>> > }
>> >
>> > void hvm_dump_emulation_state(const char *loglvl, const char
>> >
>>> On 20.09.17 at 17:12, wrote:
> On Tue, Sep 19, 2017 at 09:04:44AM -0600, Jan Beulich wrote:
>> >>> On 18.09.17 at 21:37, wrote:
>> > On Tue, Sep 12, 2017 at 02:57:04AM -0600, Jan Beulich wrote:
>> >> >>> On 12.09.17 at 02:22, wrote:
>> >> > If I compile the test-case under ARM32 it works OK
Roger Pau Monne writes ("[PATCH v2 02/21] libxl: introduce a way to mark fields
as deprecated in the idl"):
> The deprecation involves generating a function that copies the
> deprecated fields into it's new location if the new location has not
> been set.
Hi. We had an IRL conversation which I w
>>> On 20.09.17 at 17:20, wrote:
> On Wed, Sep 20, 2017 at 12:30 AM, Jan Beulich wrote:
> On 20.09.17 at 00:23, wrote:
>>> Yeap, the shim pretty simply removed the .reloc section as it was
>>> marked discardable and did the relocations for Xen. So with that
>>> removed from the shim I no lon
1 - 100 of 204 matches
Mail list logo
