>>> On 26.12.16 at 07:56, wrote:
> On 16-12-22 09:13:43, Jan Beulich wrote:
>> >>> On 14.12.16 at 05:07, wrote:
>> > So, we need define a socket info data structure, 'struct
>> > psr_socket_info' to manage information per socket. It contains a
>> > reference count array according to COS ID and a
>-Original Message-
>From: Jan Beulich [mailto:jbeul...@suse.com]
>Sent: Tuesday, January 03, 2017 3:35 PM
>To: Xuquan (Quan Xu)
>Cc: Andrew Cooper; George Dunlap; yang.zhang...@gmail.com; Chao Gao;
>Jun Nakajima; Kevin Tian; Lan Tianyu; xen-devel@lists.xen.org
>Subject: RE: [PATCH v4] x8
>>> On 03.01.17 at 09:15, wrote:
>
>>-Original Message-
>>From: Jan Beulich [mailto:jbeul...@suse.com]
>>Sent: Tuesday, January 03, 2017 3:35 PM
>>To: Xuquan (Quan Xu)
>>Cc: Andrew Cooper; George Dunlap; yang.zhang...@gmail.com; Chao Gao;
>>Jun Nakajima; Kevin Tian; Lan Tianyu; xen-devel
On 17-01-03 01:00:37, Jan Beulich wrote:
> >>> On 26.12.16 at 07:56, wrote:
> > On 16-12-22 09:13:43, Jan Beulich wrote:
> >> >>> On 14.12.16 at 05:07, wrote:
> >> > If Dom2 has same CBM values, it can reuse these registers which COS_ID=1.
> >> > That means, both Dom1 and Dom2 use same COS regist
Hi All,
This is my first mail to this mail list, and nice to meet all of you!
Right now I'm porting XEN 4.8 to an ARMv8 board and I had met some problems
with domU's pseudo physical address mapping.
Here is my situation:
I have a display control hardware that can move data from framebuffer to a
>>> On 23.12.16 at 13:24, wrote:
> 31d41d7b tried to make debug affect tools build only but failed to take
> care of debug_symbols (which appends "-g" to CFLAGS).
>
> Move both to tools/Rules.mk at once in this patch.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
>>> On 23.12.16 at 13:24, wrote:
> @@ -146,7 +146,7 @@ SHLIB_libxenvchan = $(SHDEPS_libxenvchan)
> -Wl,-rpath-link=$(XEN_LIBVCHAN)
>
> ifeq ($(debug),y)
> # Disable optimizations and enable debugging information for macros
> -CFLAGS += -O0 -g3 -fno-omit-frame-pointer
> +CFLAGS += -O0 -fno-om
>>> On 28.12.16 at 19:22, wrote:
> Now, we have two hypercalls XEN_DOMCTL_memory_mapping and
> XENMEM_add_to_physmap_range having two distinct behavior when mapping an
> MMIO into a guest.
>
> We should at least return an error, even if DOM0 decides to ignore it.
>
> I am open to any other sug
>>> On 03.01.17 at 09:49, wrote:
> On 17-01-03 01:00:37, Jan Beulich wrote:
>> >>> On 26.12.16 at 07:56, wrote:
>> > On 16-12-22 09:13:43, Jan Beulich wrote:
>> >> >>> On 14.12.16 at 05:07, wrote:
>> >> > +struct feat_node;
>> >> > +
>> >> > +/*
>> >> > + * This structure defines feature operati
flight 104006 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104006/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7c6075e2546dd818b7b87090a983429b1942796a
baseline version:
ovmf 8ad05bd26b4850b5ed898
On 17-01-03 02:12:53, Jan Beulich wrote:
> >>> On 03.01.17 at 09:49, wrote:
> > On 17-01-03 01:00:37, Jan Beulich wrote:
> >> >>> On 26.12.16 at 07:56, wrote:
> >> > On 16-12-22 09:13:43, Jan Beulich wrote:
> >> >> >>> On 14.12.16 at 05:07, wrote:
> >> >> > +struct feat_node;
> >> >> > +
> >> >>
flight 104007 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104007/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 03.01.17 at 11:28, wrote:
> Do you have any comment to other patches?
Well, I'll get to them as time permits.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Juergen Gross writes ("Stale Xenstore entries after start of domU with
stubdom"):
> Anyone an idea why I have additional stale Xenstore entries each time
> I've started a new domU with a stubdom? After 4 such starts I have:
>
> vm = ""
> -0100--fd7f-489bdb5a = ""
> memory = "66
Ian Jackson writes ("Re: Stale Xenstore entries after start of domU with
stubdom"):
> What is the uuid ? It's probably the stubdom or the main domain.
> (Try `xl list -l'.)
Never mind, I have just realised that Wei's patch (below) is a reply
to this.
Wei Liu writes ("[PATCH] libxl: fix libxl_se
Since c/s 0888d36b "x86/emul: Correct the decoding of SReg3 operands",
x86_seg_* have followed hardware encodings, meaning that this translation
table is now an identiy transform.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
---
xen/a
Comparing 3 integers is more efficient than using strcmp(), and is more useful
to the gcv_guest case than having to fabricate a suitable string to pass. The
gcv_host cases have both options easily to hand, and experimentally, the
resulting code is more efficient.
While modifying get_cpu_vendor(),
Xen only has CPU drivers for Intel, Centaur and AMD. All other contributions
to X86_VENDOR_NUM simply make the cpu_devs[] array longer, reducing the
efficiency of get_cpu_vendor()
There is one remaning hidden reference to X86_VENDOR_CYRIX in the MTRR code.
However, as far as I can tell, Cyrix nev
>>> On 03.01.17 at 12:58, wrote:
> Since c/s 0888d36b "x86/emul: Correct the decoding of SReg3 operands",
> x86_seg_* have followed hardware encodings, meaning that this translation
> table is now an identiy transform.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan
>>> On 03.01.17 at 13:06, wrote:
> Xen only has CPU drivers for Intel, Centaur and AMD. All other contributions
> to X86_VENDOR_NUM simply make the cpu_devs[] array longer, reducing the
> efficiency of get_cpu_vendor()
>
> There is one remaning hidden reference to X86_VENDOR_CYRIX in the MTRR co
>>> On 03.01.17 at 13:06, wrote:
> Comparing 3 integers is more efficient than using strcmp(), and is more useful
> to the gcv_guest case than having to fabricate a suitable string to pass. The
> gcv_host cases have both options easily to hand, and experimentally, the
> resulting code is more eff
On 03/01/17 12:40, Jan Beulich wrote:
On 03.01.17 at 13:06, wrote:
>> Comparing 3 integers is more efficient than using strcmp(), and is more
>> useful
>> to the gcv_guest case than having to fabricate a suitable string to pass.
>> The
>> gcv_host cases have both options easily to hand, an
>>> On 03.01.17 at 13:41, wrote:
> On 03/01/17 12:40, Jan Beulich wrote:
>> For the patch itself
>> Reviewed-by: Jan Beulich
>
> Does this still stand if I split the patch into two, for easier backport?
Yes.
Jan
___
Xen-devel mailing list
Xen-devel
This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc). Use the
guaranteed 32-bit underscore prefixed names for now where appropriate.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/
This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc).
Note that the result is not fully consistent until after at least one
more patch is in place, primarily to limit patch size (by trying to not
touch the same line twice).
This involves protmode_load_seg() accepting x86_seg_none as input, with
the meaning to
- suppress any exceptions other than #PF,
- not commit any state.
Signed-off-by: Jan Beulich
---
v3: Re-base.
v2: Extend commit message and add a respective code comment. Add
ASSERT()s to ensure/document th
On 03/01/17 13:01, Jan Beulich wrote:
> @@ -1321,10 +1321,10 @@ static void virtual_vmexit(struct cpu_us
> if ( lm_l1 != lm_l2 )
> paging_update_paging_modes(v);
>
> -regs->eip = get_vvmcs(v, HOST_RIP);
> -regs->esp = get_vvmcs(v, HOST_RSP);
> +regs->rip = get_vvmcs(v, H
Most invocations of the instruction emulator are for VM exits where the
set of legitimate instructions (i.e. ones capable of causing the
respective exit) is rather small. Restrict the permitted sets via a new
callback, at once eliminating the abuse of handle_mmio() for non-MMIO
operations.
Signed-
flight 104010 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104010/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 03/01/17 13:01, Jan Beulich wrote:
> This is in preparation of eliminating the mis-naming of 64-bit fields
> with 32-bit register names (eflags instead of rflags etc).
>
> Note that the result is not fully consistent until after at least one
> more patch is in place, primarily to limit patch siz
On 24/12/16 09:52, Shyam Saini wrote:
> Replace BUG() with BUG_ON() using coccinelle
>
> Signed-off-by: Shyam Saini
Committed to xen/tip.git for-linus-4.10
Thanks,
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen
This run is configured for baseline tests only.
flight 68309 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68309/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7c6075e2546dd818b7b87090a983429b1942796a
baseline v
Noone else needs to include it since it is only useful to code
that can made domctl calls. And public domctl.h can only be included
by the toolstack or the hypervisor.
Signed-off-by: Boris Ostrovsky
---
New in v6 (not required by the series).
Q: Should include/public/hvm/save.h have the same gua
This domctl will allow toolstack to read and write some
ACPI registers. It will be available to both x86 and ARM
but will be implemented first only for x86
Signed-off-by: Boris Ostrovsky
---
CC: Daniel De Graaf
---
Changes in v6:
* Fold xen_acpi_access into xen_domctl_acpi_access
* Some new erro
PVH guests do not have IOAPIC which typically generates an SCI. For
those guests SCI will be provided as a virtual interrupt.
Copy VIRQ_MCA definition from of xen-mca.h to xen.h to keep all
x86-specific VIRQ_ARCH_* in one place. (However, because we don't
want to require inclusion of xen.h in xen-
Currently HVM guests that use upstream qemu do not update xenstore's
availability entry for VCPUs. While it is not strictly necessary for
hotplug to work, xenstore ends up not reflecting actual status of
VCPUs. We should fix this.
Signed-off-by: Boris Ostrovsky
---
tools/libxl/libxl.c | 6 --
Signed-off-by: Boris Ostrovsky
---
Changes in v6:
* Adjustments to to patch 4 changes.
* Added a spinlock for VCPU map access
* Return an error on guest trying to write VCPU map
xen/arch/x86/hvm/acpi.c | 57 +++-
xen/include/asm-x86/hvm/domain.h | 1
This series adds support for ACPI-based VCPU hotplug for unprivileged
PVH guests.
Main changes in v6:
* Generate SCI on VCPU map update by domctl
* Simplify public domctl structure
* Make ACPI registers accessible only by guest (and not by domctl)
* Update VCPU map under lock
* Fix pointer update
PVH guests will have ACPI accesses emulated by the hypervisor as
opposed to QEMU (as is the case for HVM guests). This patch installs
handler for accesses to PM1A, GPE0 (which is added to struct
hvm_hw_acpi) and VCPU map. Logic for the handler will be provided
by a later patch.
Whether or not the
Provide libxc interface for accessing ACPI via XEN_DOMCTL_acpi_access.
When a VCPU is hot-(un)plugged to/from a PVH guest update VCPU map
by writing to ACPI's XEN_ACPI_CPU_MAP register and then set GPE0
status bit in GPE0.status.
Signed-off-by: Boris Ostrovsky
---
Changes in v6:
* Fix xc_acpi_ac
ACPI builder marks VCPUS set in vcpu_online map as enabled in MADT.
With ACPI-based CPU hotplug we only want VCPUs that are started by
the guest to be marked as such. Remaining VCPUs will be set to
"enable" by AML code during hotplug.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek W
Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek Wilk
---
CC: George Dunlap
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
---
Changes in v6:
* No GPE0 update is needed anymore.
docs/misc/hvmlite.markdown | 11 +++
1 file changed, 11 insertions(+)
diff
Signed-off-by: Boris Ostrovsky
---
Can't generate SCI over event channel during is an event
is enabled and pending:
* v->virq_to_evtchn is not initialized yet (it's done by guest)
* The SCI is sent immediately after event is made pending so it's
not possible to miss it (at least for the only eve
Subsequent domctl access VCPU map will use the same code. We create
acpi_cpumap_access_common() routines in anticipation of these changes.
Signed-off-by: Boris Ostrovsky
---
Changes in v6:
* ACPI registers are only accessed by guest code (not by domctl), thus
acpi_access_common() is no longer
Send and SCI when VCPU map is updated by domctl or when guest sets
GPE0 enable bit and status bit is already set.
Also update send_guest_global_virq() to handle cases when VCPU0
is offlined.
Signed-off-by: Boris Ostrovsky
---
Changes in v6:
* Change conditions causing the SCI to be generated:
>>> On 03.01.17 at 14:30, wrote:
> On 03/01/17 13:01, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate.c
>> @@ -21,6 +21,8 @@
>> #undef cpuid
>> #undef wbinvd
>>
>> +#define r(name) r ## name
>> +
>
> Hmm. I am no overwhelmed with this syntax, but I ca
On 03/01/17 14:12, Jan Beulich wrote:
>
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
>>> @@ -583,41 +583,9 @@ x86_emulate(
>>> const struct x86_emulate_ops *ops);
>>>
>>> #ifndef NDEBUG
>>> -/*
>>> - * In debug builds, wrap x86_emulate()
Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict
-Werror checking"):
> Alistair Francis 12/22/16 8:14 PM >>>
> >Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
> >as I still see warnings/errors when building: tools/kconfig/conf.c.
>
> Well, it's q
Regularly, when a new header is created in include/uapi/, the developer
forgets to add it in the corresponding Kbuild file. This error is usually
detected after the release is out.
In fact, all headers under include/uapi/ should be exported, so let's
use wildcards.
After this patch, the following
>>> On 03.01.17 at 15:38, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict
> -Werror checking"):
>> Alistair Francis 12/22/16 8:14 PM >>>
>> >Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
>> >as I still see warnings/errors when building
> +
> +#define AVIC_DOORBELL 0xc001011b
MSR_AVIC_DOORBELL (and it should probably go to include/asm-x86/msr-index.h)
> +
> +#define AVIC_HPA_SHIFT 12
Is there a reason not to use regular PAGE_SHIFT?
> +#define AVIC_HPA_MASK (((1ULL << 40) - 1) << AVIC_HPA_SHIFT)
> +#define
>>> On 03.01.17 at 15:12, wrote:
On 03.01.17 at 14:30, wrote:
>> On 03/01/17 13:01, Jan Beulich wrote:
>>> @@ -2716,36 +2716,36 @@ x86_emulate(
>>> struct segment_register cs, sreg;
>>>
>>> case 0x00 ... 0x05: add: /* add */
>>> -emulate_2op_SrcV("add", src, dst, _reg
flight 104009 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104009/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 32ea56f0a65b80324e3e651432bdf496a6fc55b7
baseline version:
ovmf 7c6075e2546dd818b7b87
On 03/01/17 13:02, Jan Beulich wrote:
> This involves protmode_load_seg() accepting x86_seg_none as input, with
> the meaning to
> - suppress any exceptions other than #PF,
> - not commit any state.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper , although I note
you do introduce new u
>>> On 03.01.17 at 15:56, wrote:
> On 03/01/17 13:02, Jan Beulich wrote:
>> This involves protmode_load_seg() accepting x86_seg_none as input, with
>> the meaning to
>> - suppress any exceptions other than #PF,
>> - not commit any state.
>>
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Andrew C
On 03/01/17 13:10, Jan Beulich wrote:
> Most invocations of the instruction emulator are for VM exits where the
> set of legitimate instructions (i.e. ones capable of causing the
> respective exit) is rather small. Restrict the permitted sets via a new
> callback, at once eliminating the abuse of h
On Fri, Dec 9, 2016 at 12:59 PM, Tamas K Lengyel
wrote:
> The only caller of this function is get_page_from_gva which already takes
> a vcpu pointer as input. Pass this along to make the function in-line with
> its intended use-case.
>
> Signed-off-by: Tamas K Lengyel
> ---
> Cc: Stefano Stabelli
On Fri, Dec 9, 2016 at 12:59 PM, Tamas K Lengyel
wrote:
> This patch relocates mem_access components that are currently mixed with p2m
> code into separate files. This better aligns the code with similar subsystems,
> such as mem_sharing and mem_paging, which are already in separate files. There
>
> +
> +static int avic_ldr_write(struct vcpu *v, u8 g_phy_id, u32 ldr, bool valid)
> +{
> +struct avic_log_apic_id_ent *entry, new_entry;
> +u32 *bp = avic_get_bk_page_entry(v, APIC_DFR);
dfr would be a better name (and you use it in avic_handle_dfr_update()).
Also, 'logical' instead of
From: Oleksandr Andrushchenko
Hi, all!
I am working on adding multi-touch support to the existing
kbdif protocol and would like to request for comments on the
below patch.
The aim is to provide multi-touch support to unprivileged
domains which may employ multiple virtual displays.
Thus, the prot
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
xen/include/public/io/kbdif.h | 64 +++
1 file changed, 64 insertions(+)
diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index 2d2aebd..ad94b53 100644
---
On 12/31/2016 12:45 AM, Suravee Suthikulpanit wrote:
> Add hooks to manage AVIC data structure during vcpu scheduling.
>
> Signed-off-by: Suravee Suthikulpanit
> Cc: Konrad Rzeszutek Wilk
> Cc: Jan Beulich
> Cc: Boris Ostrovsky
> ---
> xen/arch/x86/hvm/svm/avic.c | 78
> ++
flight 104011 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104011/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Fri, Dec 23, 2016 at 12:13:47PM -0500, Boris Ostrovsky wrote:
> On 12/23/2016 11:02 AM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Dec 23, 2016 at 10:35:10AM -0500, Boris Ostrovsky wrote:
> >> On 12/23/2016 10:31 AM, Konrad Rzeszutek Wilk wrote:
> But this still assumes that dom0 handles ACPI
From: Nicolas Dichtel
Date: Tue, 3 Jan 2017 15:35:44 +0100
> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
>
> In fact, all headers under include/uapi/ shou
>
> +static void avic_dump(unsigned char ch)
> +{
> +struct domain *d;
> +struct vcpu *v;
> +
> +printk("*** SVM AVIC Statistics **\n");
> +
> +rcu_read_lock(&domlist_read_lock);
> +
> +for_each_domain ( d )
> +{
> +if ( !is_hvm_domain(d) )
||
On 03/01/17 16:01, Boris Ostrovsky wrote:
>>
>> +static void avic_dump(unsigned char ch)
>> +{
>> +struct domain *d;
>> +struct vcpu *v;
>> +
>> +printk("*** SVM AVIC Statistics **\n");
>> +
>> +rcu_read_lock(&domlist_read_lock);
>> +
>> +for_each_domain (
>>> On 03.01.17 at 16:22, wrote:
> On 03/01/17 13:10, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -1039,6 +1039,17 @@ static int hvmemul_cmpxchg(
>> return hvmemul_write(seg, offset, p_new, bytes, ctxt);
>> }
>>
>> +static int hvmemul_va
>>> On 03.01.17 at 16:39, wrote:
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -45,6 +45,19 @@
> */
> #define XENKBD_TYPE_POS 4
>
> +/*
> + * Multi-touch event
> + * Capable backend sets feature-multi-touch in xenstore.
> + * Frontend requests feature by
flight 68308 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68308/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like
68277
test-armhf-
>>> On 03.01.17 at 15:04, wrote:
> Noone else needs to include it since it is only useful to code
> that can made domctl calls. And public domctl.h can only be included
> by the toolstack or the hypervisor.
>
> Signed-off-by: Boris Ostrovsky
> ---
> New in v6 (not required by the series).
>
> Q
>>> On 03.01.17 at 15:04, wrote:
> --- a/docs/misc/hvmlite.markdown
> +++ b/docs/misc/hvmlite.markdown
> @@ -75,3 +75,14 @@ info structure that's passed at boot time (field
> rsdp_paddr).
>
> Description of paravirtualized devices will come from XenStore, just as it's
> done for HVM guests.
>
This run is configured for baseline tests only.
flight 68310 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68310/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 32ea56f0a65b80324e3e651432bdf496a6fc55b7
baseline v
Happy New Year!
This is a very minor rebase from v5. It only moves a few headers around.
I think this series should be ready to be queued up for 4.11.
Thanks,
Laura
Laura Abbott (11):
lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
mm/cma: Cleanup highmem check
arm64: Move some macros under
On 03/01/17 16:19, Jan Beulich wrote:
On 03.01.17 at 16:22, wrote:
>> On 03/01/17 13:10, Jan Beulich wrote:
>>> --- a/xen/arch/x86/hvm/emulate.c
>>> +++ b/xen/arch/x86/hvm/emulate.c
>>> @@ -1039,6 +1039,17 @@ static int hvmemul_cmpxchg(
>>> return hvmemul_write(seg, offset, p_new, bytes,
On Thu, Dec 15, 2016 at 12:27:17PM +, Andre Przywara wrote:
> From: Ian Campbell
>
> If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to
> the usual ttyAMA0 otherwise.
>
> Signed-off-by: Ian Campbell
> Signed-off-by: Christoffer Dall
> Signed-off-by: Andre Przywara
>
On 08/12/16 23:40, Boris Ostrovsky wrote:
On 12/08/2016 05:21 PM, Andrew Cooper wrote:
On 08/12/2016 19:18, Stefano Stabellini wrote:
Of course even the largest virtual machine today (2TB on Amazon AFAIK)
is not close to reaching the current memory limit, but it's just a
matter of time.
On Thu, Dec 15, 2016 at 12:27:13PM +, Andre Przywara wrote:
> These patches allow to include a Xen hypervisor binary into a boot-wrapper
> ELF file, so that a Foundation Platform or a Fast Model can boot a Xen
> system (including a Dom0 kernel).
Thanks!
I've applied the series and pushed it o
On Thu, Dec 29, 2016 at 01:45:54PM +, George Dunlap wrote:
> Hey Ronald! Looks like you're getting going pretty well here.
>
> At a high level: I think I began by saying that this would probably all
> be a single patch. But I think it would probably be easier to review
> the different decisi
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
---
xen/arch/x86/hvm/svm/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 89daa39..04a7b6
On Wed, 28 Dec 2016, George Dunlap wrote:
> On Tue, Dec 20, 2016 at 11:09 PM, Stefano Stabellini
> wrote:
> > On Tue, 20 Dec 2016, Jan Beulich wrote:
> >> >>> On 20.12.16 at 01:47, wrote:
> >> > ## Design Phase
> >> >
> >> > The first step toward acceptance of a new PV protocol is to write a
> >>
On Mon, 2 Jan 2017, Juergen Gross wrote:
> On 28/12/16 01:47, Jiandi An wrote:
> > Ensure all reserved fields of xatp are zero before making
> > hypervisor call to XEN in xen_map_device_mmio().
> > xenmem_add_to_physmap_one() in XEN fails the mapping request if
> > extra.res reserved field in xatp
On Tue, 3 Jan 2017, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky
> Reviewed-by: Konrad Rzeszutek Wilk
> ---
> CC: George Dunlap
> CC: Konrad Rzeszutek Wilk
> CC: Stefano Stabellini
> CC: Tim Deegan
> ---
> Changes in v6:
> * No GPE0 update is needed anymore.
>
> docs/misc/hvmlite
On 3 January 2017 at 17:50, Al Stone wrote:
> On 12/23/2016 05:51 AM, Roger Pau Monné wrote:
>> Hello,
>>
>> I've been looking into the STAO specification[0], because I think it would
>> also
>> be useful for x86 PVHv2 Dom0, but I'm not really sure how is Xen supposed to
>> use it.
>>
>> Xen does
On 01/03/2017 09:04 AM, Boris Ostrovsky wrote:
This domctl will allow toolstack to read and write some
ACPI registers. It will be available to both x86 and ARM
but will be implemented first only for x86
Signed-off-by: Boris Ostrovsky
Acked-by: Daniel De Graaf
--
Daniel De Graaf
National S
On 12/19/2016 11:03 PM, Doug Goldstein wrote:
On 12/19/16 10:02 AM, Doug Goldstein wrote:
On 12/14/16 3:09 PM, Daniel De Graaf wrote:
On 12/12/2016 09:00 AM, Anshul Makkar wrote:
During guest migrate allow permission to prevent
spurious page faults.
Prevents these errors:
d73: Non-privileged (
On Fri, 23 Dec 2016, Roger Pau Monné wrote:
> Hello,
>
> I've been looking into the STAO specification[0], because I think it would
> also
> be useful for x86 PVHv2 Dom0, but I'm not really sure how is Xen supposed to
> use it.
>
> Xen doesn't have an AML parser, so I'm not sure how is it suppos
On Thu, 22 Dec 2016, Jan Beulich wrote:
> >>> On 20.12.16 at 23:50, wrote:
> > On Tue, 20 Dec 2016, Jan Beulich wrote:
> >> >>> On 20.12.16 at 00:01, wrote:
> >> > This is actually not an ARM specific question, so changing the subject
> >> > and CC'ing more people.
> >> >
> >> > On Wed, 14 Dec 2
> We can provide a crafted MADT that reflects the number of vCPUs available to
> Dom0 at boot time, let Dom0 find the Processor objects in the ACPI namespace
> and perform pCPU hotplug as it's been done until now. Then for Dom0 vCPU
> hotplug we would need to use the hypercall interface as it's us
flight 104008 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104008/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 6 xen-bootfail REGR. vs. 104004
test-armhf-armhf-x
On Wed, 28 Dec 2016, Julien Grall wrote:
> (CC Andrew and Jan)
>
> Hi Stefano,
>
> On 20/12/16 22:33, Stefano Stabellini wrote:
> > On Tue, 20 Dec 2016, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 20/12/2016 00:54, Stefano Stabellini wrote:
> > > > On Mon, 19 Dec 2016, Julien Grall wrot
On 01/03/2017 11:58 AM, Jan Beulich wrote:
On 03.01.17 at 15:04, wrote:
>> --- a/docs/misc/hvmlite.markdown
>> +++ b/docs/misc/hvmlite.markdown
>> @@ -75,3 +75,14 @@ info structure that's passed at boot time (field
>> rsdp_paddr).
>>
>> Description of paravirtualized devices will come fro
On Wed, 28 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 21/12/16 22:12, Stefano Stabellini wrote:
> > On Wed, 21 Dec 2016, Julien Grall wrote:
> > > On 20/12/2016 20:53, Stefano Stabellini wrote:
> > > > On Tue, 20 Dec 2016, Julien Grall wrote:
> > > > > On 19/12/2016 21:24, Stefano Stabelli
On 01/03/2017 06:28 PM, Jan Beulich wrote:
On 03.01.17 at 16:39, wrote:
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -45,6 +45,19 @@
*/
#define XENKBD_TYPE_POS 4
+/*
+ * Multi-touch event
+ * Capable backend sets feature-multi-touch in xenstore.
+ * F
On Thu, 29 Dec 2016, Bhupinder Thakur wrote:
> On 28 December 2016 at 23:19, Julien Grall wrote:
> > On 21/12/16 22:12, Stefano Stabellini wrote:
> >>
> >> On Wed, 21 Dec 2016, Julien Grall wrote:
> >>>
> >>> On 20/12/2016 20:53, Stefano Stabellini wrote:
>
> On Tue, 20 Dec 2016, Julien
On 01/03/2017 01:19 PM, Stefano Stabellini wrote:
> On Tue, 3 Jan 2017, Boris Ostrovsky wrote:
>> Signed-off-by: Boris Ostrovsky
>> Reviewed-by: Konrad Rzeszutek Wilk
>> ---
>> CC: George Dunlap
>> CC: Konrad Rzeszutek Wilk
>> CC: Stefano Stabellini
>> CC: Tim Deegan
>> ---
>> Changes in v6:
> diff --git a/xen/arch/x86/hvm/acpi.c b/xen/arch/x86/hvm/acpi.c
> new file mode 100644
> index 000..04901c1
> --- /dev/null
> +++ b/xen/arch/x86/hvm/acpi.c
> @@ -0,0 +1,24 @@
> +/* acpi.c: ACPI access handling
> + *
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
2
On Thu, Dec 22, 2016 at 03:58:18PM +0200, Andy Shevchenko wrote:
> On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote:
> > +#define LINKTABLE_FOR_EACH(pointer, tbl)
>
> Hmm... SOMEONE LIKES CAPITAL LETTERS FOR everything, right? :-)
>
> I would expect more standa
On Thu, Dec 22, 2016 at 04:08:22PM +0200, Andy Shevchenko wrote:
> On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote:
> > Move the __jump_table from the a custom section solution
> > to a generic solution, this avoiding extra vmlinux.lds.h
> > customizations.
> >
> > This also demos the u
On Tuesday, January 3, 2017 3:35:44 PM CET Nicolas Dichtel wrote:
> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
>
> In fact, all headers under include/uapi/
1 - 100 of 118 matches
Mail list logo
