>>> On 27.06.16 at 18:54, wrote:
> Jim Fehlig writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver
> breakage -- where to define LIBXL_API_VERSION?"):
>> On 06/27/2016 10:12 AM, Ian Jackson wrote:
>> > Does libvirt have stable release branches ? One approach would be to
>> > have oss
On June 27, 2016 11:21 PM, Jan Beulich wrote:
> >>> On 27.06.16 at 14:56, wrote:
> > On June 27, 2016 4:24 PM, Jan Beulich wrote:
> >> >>> On 24.06.16 at 07:51, wrote:
> >> > @@ -199,24 +199,73 @@ static int __must_check
> >> queue_invalidate_wait(struct iommu *iommu,
> >> > return -EOPNOT
>>> On 27.06.16 at 18:54, wrote:
> The two new defines will be a typesafe version of resp. INVALID_GFN and
> INVALID_MFN.
>
> Signed-off-by: Julien Grall
Ultimately we'll likely want it the other way around naming-wise,
but I understand that's far beyond what this series can and should
do.
Ack
>>> On 27.06.16 at 18:54, wrote:
> This patch is a mechanical replacement. Command used:
>
> 42sh> ack -l "_mfn\(INVALID_MFN\)" | xargs sed -i -e
> 's/_mfn(INVALID_MFN)/INVALID_MFN_T/g'
Well, wait - if you do this, then I'm no longer sure my remark just
made on patch 2 holds: If you do such a
>>> On 28.06.16 at 09:06, wrote:
> On June 27, 2016 11:21 PM, Jan Beulich wrote:
>> >>> On 27.06.16 at 14:56, wrote:
>> > On June 27, 2016 4:24 PM, Jan Beulich wrote:
>> >> >>> On 24.06.16 at 07:51, wrote:
>> >> > @@ -199,24 +199,73 @@ static int __must_check
>> >> queue_invalidate_wait(struct
On 28/06/2016 08:16, Jan Beulich wrote:
On 27.06.16 at 18:54, wrote:
>> The two new defines will be a typesafe version of resp. INVALID_GFN and
>> INVALID_MFN.
>>
>> Signed-off-by: Julien Grall
> Ultimately we'll likely want it the other way around naming-wise,
> but I understand that's far
>>> On 27.06.16 at 20:08, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3376,7 +3376,29 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
> write_debugreg(6, exit_qualification | DR_S
flight 96321 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96321/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 87893
build-amd64-libvi
>>> On 28.06.16 at 03:58, wrote:
> As you know, SMAP/SMEP may affect the 32-bit pv guests, after discussed
> internally, our current idea is that we can just disable this two feature for
> Xen hypervisor itself, hence only enable it for HVM guests. Do you think this
> is acceptable from your pe
>>> On 28.06.16 at 07:51, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3474,6 +3474,14 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
> unsigned int *ebx,
>xstate_sizes[_XSTATE_BNDCSR]);
> }
>
> +
>>> On 28.06.16 at 09:29, wrote:
> On 28/06/2016 08:16, Jan Beulich wrote:
> On 27.06.16 at 18:54, wrote:
>>> The two new defines will be a typesafe version of resp. INVALID_GFN and
>>> INVALID_MFN.
>>>
>>> Signed-off-by: Julien Grall
>> Ultimately we'll likely want it the other way around n
>>> On 28.06.16 at 00:28, wrote:
> (XEN) [2016-06-27 22:11:41.712] [ Xen-4.7.0 x86_64 debug=n Not tainted
> ]
> (XEN) [2016-06-27 22:11:41.712] CPU:0
> (XEN) [2016-06-27 22:11:41.712] RIP:e008:[]
> domain_relinquish_resources+0x10/0x2f0
> (XEN) [2016-06-27 22:11:41.712] RFLAGS
Thanks for your advice, I will make a change right now.
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, June 28, 2016 3:49 PM
To: Kang, Luwei
Cc: andrew.coop...@citrix.com; Peng, Chao P ; Wang, Yong
Y ; xen-devel@lists.xen.org
Subject: Re: [PATCH] x86/cp
From: Kai Huang
Below commit introduced a new macro MSR_IA32_FEATURE_CONTROL for
IA32_FEATURE_CONTROL MSR but it didn't remove old IA32_FEATURE_CONTROL_MSR
macro. The new one has better naming convention, so remove the old as a
duplication. Also move the macros of bit definition of IA32_FEATURE_C
>>> On 28.06.16 at 10:12, wrote:
> From: Kai Huang
On the 24th I had asked you privately to please follow Xen patch
submission rules: Patches get sent _to_ the list, and maintainers
get _cc_-ed. People receiving mails may have rules in place in their
mail systems to pre-sort incoming traffic acc
On 28/06/16 06:51, Luwei Kang wrote:
> @@ -1136,9 +1136,16 @@ void pv_cpuid(struct cpu_user_regs *regs)
> case XSTATE_CPUID:
>
> if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
> +{
> domain_cpuid(currd, 1, 0, &tmp, &tmp, &_ecx, &tmp);
> +
OK, no problem.
-Original Message-
From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: Tuesday, June 28, 2016 4:47 PM
To: Kang, Luwei ; xen-devel@lists.xen.org
Cc: jbeul...@suse.com; Wang, Yong Y ; Peng, Chao P
Subject: Re: [PATCH] x86/cpuid: AVX-512 Feature Detection
On 28/0
On 6/28/2016 8:37 PM, Jan Beulich wrote:
On 28.06.16 at 10:12, wrote:
From: Kai Huang
On the 24th I had asked you privately to please follow Xen patch
submission rules: Patches get sent _to_ the list, and maintainers
get _cc_-ed. People receiving mails may have rules in place in their
mail
flight 96322 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96322/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
>>> On 21.06.16 at 18:04, wrote:
> @@ -65,6 +66,48 @@ altp2m_vcpu_destroy(struct vcpu *v)
> vcpu_unpause(v);
> }
>
> +int
> +hvm_altp2m_init( struct domain *d) {
Coding style (stray blank and misplaced brace).
> +int rv = 0;
I guess rc or ret would be the more conventional names
Hi Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
> As the number of I/O handlers increase, the overhead associated with
> linear lookup also increases. The system might have maximum of 144
> (assuming CONFIG_NR_CPUS=128) mmio handlers. In worst case scenario,
> it would require 144 iterati
>>> On 21.06.16 at 18:04, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5228,7 +5228,7 @@ static int do_altp2m_op(
>
> if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
> (a.cmd != HVMOP_altp2m_set_domain_state) &&
> - !d->arch.altp2m_active )
>
Hi Dirk,
On 27/06/16 08:53, Dirk Behme wrote:
With the Linux kernel commits
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/arm64/booting.txt?id=4370eec05a887b0cd4392cd5dc5b2713174745c0
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
Hi Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
The function acpi_table_parse_madt() does the same functionality as
function acpi_parse_entries() expect it takes a few arguments.
Signed-off-by: Shanker Donthineni
Reviewed-by: Julien Grall
Regards,
---
xen/arch/arm/gic-v3.c | 2
On 27/06/16 22:59, Doug Goldstein wrote:
> On 6/27/16 7:59 AM, Andrew Cooper wrote:
>> On 27/06/16 13:43, Juergen Gross wrote:
>>> I'm just writing some patches to make it easy to switch between
>>> xenstore daemon and xenstore domain. My plan is to achieve this
>>> by a global configuration file c
Hi Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
Add a new function to parse GICR subtable and move the code that
is specific to GICR table to a new function without changing the
function gicv3_acpi_init() behavior.
Signed-off-by: Shanker Donthineni
Acked-by: Julien Grall
Regards,
On 27/06/16 21:59, Doug Goldstein wrote:
> On 6/27/16 7:59 AM, Andrew Cooper wrote:
>> On 27/06/16 13:43, Juergen Gross wrote:
>>> I'm just writing some patches to make it easy to switch between
>>> xenstore daemon and xenstore domain. My plan is to achieve this
>>> by a global configuration file c
Hello Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
@@ -1397,6 +1408,36 @@ gic_acpi_parse_madt_distributor(struct
acpi_subtable_header *header,
}
static int __init
+gic_acpi_parse_cpu_redistributor(struct acpi_subtable_header *header,
+ const unsigne
Hi Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
The number of Redistributor regions allowed for dom0 is hardcoded
to a define MAX_RDIST_COUNT which is 4. Some systems, especially
latest server chips, may have more than 4 redistributors. Either we
have to increase MAX_RDIST_COUNT to a bi
Jan Beulich writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver
breakage -- where to define LIBXL_API_VERSION?"):
> On 27.06.16 at 18:54, wrote:
> > OK. Thanks for the feedback. I'll go ahead with my plan with the
> > git commit ids named in my earlier email.
>
> The only (hopeful
Hi Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
Separate the code logic that does the registration of vgic_v3/v2 ops
to a new function domain_vgic_register(). The intention of this
separation is to record the required mmio count in vgic_v3/v2_init()
and pass it to function domain_io_ini
David Vrabel writes ("Re: [Xen-devel] making xenstore domain easy
configurable"):
> So I don't think we want to go down this route unless xs_restrict() can
> be made to work via the kernel interface as well.
It could, in principle, but it would have to be implemented in the
xenstore kernel driver
Hi Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
As the number of I/O handlers increase, the overhead associated with
linear lookup also increases. The system might have maximum of 144
(assuming CONFIG_NR_CPUS=128) mmio handlers. In worst case scenario,
it would require 144 iterations fo
On 28/06/16 12:45, Ian Jackson wrote:
> David Vrabel writes ("Re: [Xen-devel] making xenstore domain easy
> configurable"):
>> So I don't think we want to go down this route unless xs_restrict() can
>> be made to work via the kernel interface as well.
>
> It could, in principle, but it would have
Hi Shanker,
On 27/06/16 16:02, Shanker Donthineni wrote:
On 06/27/2016 08:35 AM, Julien Grall wrote:
Hi Shanker,
On 26/06/16 18:48, Shanker Donthineni wrote:
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 29346c6..b205461 100644
--- a/xen/include/asm-arm/doma
Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
configurable"):
> So you are telling me the xenstore domain won't work for this case?
Yes.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 2016/6/27 20:05, Boris Ostrovsky wrote:
>
>
> On 06/27/2016 06:29 AM, Julien Grall wrote:
>> (CC Boris and Doug)
>>
>> Hi Shannon,
>>
>> On 27/06/16 07:01, Shannon Zhao wrote:
>>> On 2016/6/24 1:03, Julien Grall wrote:
On 23/06/16 04:16, Shannon Zhao wrote:
[...]
> di
Hello,
On 27/06/16 14:31, sepanta s wrote:
On Sun, Jun 26, 2016 at 5:19 PM, sepanta s mailto:sapanta...@gmail.com>> wrote:
Hi,
what exactly does this module do?
sorry, not module but the function.
The function xc_domain_maximum_gpfn returns the highest frame that has
ever been map
A clue on doing this would be useful, I can't debug what is now release
code all day.
4.5 is absolutely fine. 4.6.3 (tried last night) does not fail either but
refuses to start my domU that has two nics assigned to it in a vif line.
I'm presuming other people are successfully running multiple NICs
The sorting was required by the vGIC emulation until commit
9b9d51e98edb8c5c731e2d06dfad3633053d88a4 "xen/arm: vgic-v3:
Correctly retrieve the vCPU associated to a re-distributor".
Furthermore, the code is buggy because both local variables 'l' and 'r'
point to the same region.
So drop the code w
On 25 June 2016 at 09:16, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
> ACPI tables through Xen ARM multiboot protocol.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shannon Zhao
Reviewed-by: Ard
On 28/06/16 13:03, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
> configurable"):
>> So you are telling me the xenstore domain won't work for this case?
>
> Yes.
That's rather unfortunate. So in order to be able to make xenstore
domain a common setup we
Hi Ard,
On 28/06/16 12:39, Ard Biesheuvel wrote:
On 25 June 2016 at 09:16, Shannon Zhao wrote:
From: Shannon Zhao
Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
ACPI tables through Xen ARM multiboot protocol.
Contributed-under: TianoCore Contribution Agreement 1.0
Signe
On 28 June 2016 at 14:06, Julien Grall wrote:
> Hi Ard,
>
> On 28/06/16 12:39, Ard Biesheuvel wrote:
>>
>> On 25 June 2016 at 09:16, Shannon Zhao wrote:
>>>
>>> From: Shannon Zhao
>>>
>>> Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
>>> ACPI tables through Xen ARM multiboo
Hi Jan,
On 28/06/16 08:19, Jan Beulich wrote:
On 27.06.16 at 18:54, wrote:
This patch is a mechanical replacement. Command used:
42sh> ack -l "_mfn\(INVALID_MFN\)" | xargs sed -i -e
's/_mfn(INVALID_MFN)/INVALID_MFN_T/g'
Well, wait - if you do this, then I'm no longer sure my remark just
ma
flight 96340 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96340/
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 12
On 28/06/16 12:56, Juergen Gross wrote:
> On 28/06/16 13:03, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
>> configurable"):
>>> So you are telling me the xenstore domain won't work for this case?
>> Yes.
> That's rather unfortunate. So in order to be ab
Hi Julien,
On 06/28/2016 05:49 AM, Julien Grall wrote:
Hi Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
As the number of I/O handlers increase, the overhead associated with
linear lookup also increases. The system might have maximum of 144
(assuming CONFIG_NR_CPUS=128) mmio handlers.
On 28/06/16 14:19, Shanker Donthineni wrote:
On 06/28/2016 05:49 AM, Julien Grall wrote:
On 27/06/16 21:33, Shanker Donthineni wrote:
As the number of I/O handlers increase, the overhead associated with
linear lookup also increases. The system might have maximum of 144
(assuming CONFIG_NR_CPU
>>> On 28.06.16 at 13:23, wrote:
> A clue on doing this would be useful, I can't debug what is now release
> code all day.
Well, debugging (released code or not) is what's needed, I'm afraid.
A first step would be to find out how far the corruption extends:
Considering the non-zero code bytes tha
On 28/06/16 14:42, Andrew Cooper wrote:
> On 28/06/16 12:56, Juergen Gross wrote:
>> On 28/06/16 13:03, Ian Jackson wrote:
>>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
>>> configurable"):
So you are telling me the xenstore domain won't work for this case?
>>> Yes.
>>
On 06/28/2016 07:03 AM, Shannon Zhao wrote:
>
> On 2016/6/27 20:05, Boris Ostrovsky wrote:
>>
>> On 06/27/2016 06:29 AM, Julien Grall wrote:
>>> (CC Boris and Doug)
>>>
>>> Hi Shannon,
>>>
>>> On 27/06/16 07:01, Shannon Zhao wrote:
On 2016/6/24 1:03, Julien Grall wrote:
> On 23/06/16 04:16
>>> On 28.06.16 at 10:12, wrote:
> From: Kai Huang
>
> Below commit introduced a new macro MSR_IA32_FEATURE_CONTROL for
> IA32_FEATURE_CONTROL MSR but it didn't remove old IA32_FEATURE_CONTROL_MSR
> macro. The new one has better naming convention, so remove the old as a
> duplication. Also move
Hi Julien,
On 06/28/2016 05:40 AM, Julien Grall wrote:
Hello Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
@@ -1397,6 +1408,36 @@ gic_acpi_parse_madt_distributor(struct
acpi_subtable_header *header,
}
static int __init
+gic_acpi_parse_cpu_redistributor(struct acpi_subtable_head
On 28/06/16 14:42, Andrew Cooper wrote:
> On 28/06/16 12:56, Juergen Gross wrote:
>> On 28/06/16 13:03, Ian Jackson wrote:
>>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
>>> configurable"):
So you are telling me the xenstore domain won't work for this case?
>>> Yes.
>>
On 28/06/16 14:52, Juergen Gross wrote:
> On 28/06/16 14:42, Andrew Cooper wrote:
>> On 28/06/16 12:56, Juergen Gross wrote:
>>> On 28/06/16 13:03, Ian Jackson wrote:
Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
configurable"):
> So you are telling me the xensto
On 28/06/16 14:36, Juergen Gross wrote:
> On 28/06/16 14:42, Andrew Cooper wrote:
>> On 28/06/16 12:56, Juergen Gross wrote:
>>> On 28/06/16 13:03, Ian Jackson wrote:
Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
configurable"):
> So you are telling me the xensto
ld associates __init_end, placed outside of any section by the linker
script, with the following section, resulting in a huge (wrapped, as it
would be negative) section relative offset. COFF symbol tables store
section relative addresses, and hence the above leads to assembler
truncation warnings w
On 28/06/16 15:03, Jan Beulich wrote:
> ld associates __init_end, placed outside of any section by the linker
> script, with the following section, resulting in a huge (wrapped, as it
> would be negative) section relative offset.
So in this case, the cause of the truncation is due to __init_end be
On 06/28/2016 08:51 AM, Shanker Donthineni wrote:
Hi Julien,
On 06/28/2016 05:40 AM, Julien Grall wrote:
Hello Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
@@ -1397,6 +1408,36 @@ gic_acpi_parse_madt_distributor(struct
acpi_subtable_header *header,
}
static int __init
+gic_a
On 28/06/16 15:59, Andrew Cooper wrote:
> On 28/06/16 14:36, Juergen Gross wrote:
>> On 28/06/16 14:42, Andrew Cooper wrote:
>>> On 28/06/16 12:56, Juergen Gross wrote:
On 28/06/16 13:03, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
> configu
On 28/06/16 15:58, Juergen Gross wrote:
> On 28/06/16 15:59, Andrew Cooper wrote:
>> On 28/06/16 14:36, Juergen Gross wrote:
>>> On 28/06/16 14:42, Andrew Cooper wrote:
On 28/06/16 12:56, Juergen Gross wrote:
> On 28/06/16 13:03, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [Xen-de
On 6/28/16 8:59 AM, Andrew Cooper wrote:
> On 28/06/16 14:36, Juergen Gross wrote:
>> On 28/06/16 14:42, Andrew Cooper wrote:
>>> On 28/06/16 12:56, Juergen Gross wrote:
On 28/06/16 13:03, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
> config
On 28/06/16 16:17, Doug Goldstein wrote:
> On 6/28/16 8:59 AM, Andrew Cooper wrote:
>> On 28/06/16 14:36, Juergen Gross wrote:
>>> On 28/06/16 14:42, Andrew Cooper wrote:
On 28/06/16 12:56, Juergen Gross wrote:
> On 28/06/16 13:03, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [Xen-
On 28/06/16 17:23, Andrew Cooper wrote:
> On 28/06/16 16:17, Doug Goldstein wrote:
>> On 6/28/16 8:59 AM, Andrew Cooper wrote:
>>> On 28/06/16 14:36, Juergen Gross wrote:
On 28/06/16 14:42, Andrew Cooper wrote:
> On 28/06/16 12:56, Juergen Gross wrote:
>> On 28/06/16 13:03, Ian Jackson
flight 96333 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96333/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 96299
Tests which did not succe
The sorting was required by the vGIC emulation until commit
9b9d51e98edb8c5c731e2d06dfad3633053d88a4 "xen/arm: vgic-v3:
Correctly retrieve the vCPU associated to a re-distributor".
Furthermore, the code is buggy because both local variables 'l' and 'r'
point to the same region.
So drop the code w
>>> On 28.06.16 at 16:26, wrote:
> On 28/06/16 15:03, Jan Beulich wrote:
>> ld associates __init_end, placed outside of any section by the linker
>> script, with the following section, resulting in a huge (wrapped, as it
>> would be negative) section relative offset.
>
> So in this case, the caus
Hello all,
Some of the ARM functions are mixing gfn vs mfn and even physical vs frame.
To avoid more confusion, this patch series makes use of the terminology
described in xen/include/xen/mm.h and the associated typesafe.
This series requires the patch [1] to be applied beforehand. I pushed a
br
p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename
the variable to *gfn* and use typesafe to avoid possible misusage.
Also, modify the prototype of the function to describe the range
using the start and the number of GFNs. This will avoid to wonder
whether the end if inclusive or
Also take the opportunity to convert arch/x86/debug.c to the typesafe gfn.
Signed-off-by: Julien Grall
---
Cc: Mukesh Rathor
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Paul Durrant
Cc: Boris Ostrovsky
Cc: Suravee Suthikulpanit
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: George Dunlap
Cc: Tim Deegan
More the half of the arguments of INSERT and REMOVE are the same for
each callers. Simplify the callers of apply_p2m_changes by adding new
helpers which will fill common arguments with default values.
Signed-off-by: Julien Grall
---
Changes in v5:
- Add missing Signed-off-by
Cha
The parameter 'access' is used by memaccess to restrict temporarily the
permission. This parameter should not be used for other purpose (such
as restricting permanently the permission).
The type p2m_mmio_direct will map the region Read-Write and
non-executable. Note that this is already the curren
to avoid mixing machine frame with guest frame.
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
---
Cc: Stefano Stabellini
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Tim Deegan
Cc: Wei Liu
Changes in v3:
- Use mfn_add
Most of the callers of apply_p2m_changes have a GFN, a MFN and the
number of frame to change in hand.
Rather than asking each caller to convert the frame to an address,
rework the interfaces to pass the GFN, MFN and the number of frame.
Note that it would be possible to do more clean-up in apply_
to avoid mixing machine frame with guest frame. Also rename the
parameters of the function and drop pointless PAGE_MASK in the caller.
Signed-off-by: Julien Grall
---
Changes in v4:
- Patch added
---
xen/arch/arm/domain_build.c | 8
xen/arch/arm/p2m.c | 20 +++
The correct acronym for a guest physical frame is gfn. Also use
the typesafe gfn to ensure that a guest frame is effectively used.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
Changes in v4:
- Add Stefano's acked-by
Changes in v2:
- Remove extra pair of
The x86 version of the function xenmem_add_to_physmap_one contains
variable name gpfn and gfn which make the code very confusing.
I have left unchanged for now.
Also, rename gpfn to gfn in the ARM version as the latter is the correct
acronym for a guest physical frame.
Finally, remove the trailin
A variable containing a guest frame should be compared to INVALID_GFN
and not INVALID_GFN.
Signed-off-by: Julien Grall
---
Cc: Suravee Suthikulpanit
Cc: Jan Beulich
Changes in v5:
- Patch added
---
xen/drivers/passthrough/amd/iommu_map.c | 2 +-
xen/drivers/passthrough/x86/iommu.
Also rename some variables to gfn or mfn when it does not require much
rework.
Finally replace %hu with %d when printing the domain id in
guest_physmap_add_entry (arch/x86/mm/p2m.c).
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
Acked-by: Stefano Stabellini
---
Cc: Stefano Stabellini
Cc:
The code to allocate memory when dom0 does not use direct mapping is
relying on the presence of memory node in the DT.
However, they are not present when booting using UEFI or when using
ACPI.
Rather than fixing the code, remove it because dom0 is always direct
memory mapped and therefore the cod
Also take the opportunity to convert arch/x86/debug.c to the typesafe
mfn.
Signed-off-by: Julien Grall
---
Cc: Christoph Egger
Cc: Liu Jinsong
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Mukesh Rathor
Cc: Paul Durrant
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: George Dunlap
Cc: Tim Deegan
Chan
The operation ALLOCATE is unused. If we ever need it, it could be
reimplemented with INSERT.
Signed-off-by: Julien Grall
---
Changes in v4:
- Patch added
---
xen/arch/arm/p2m.c| 67 ++-
xen/include/asm-arm/p2m.h | 3 ---
2 files c
The prototype and the declaration of p2m_lookup disagree on how the
function should be used. One expect a frame number whilst the other
an address.
Thankfully, everyone is using with an address today. However, most of
the callers have to convert a guest frame to an address. Modify
the interface to
Signed-off-by: Julien Grall
---
Changes in v4:
- Patch added
---
xen/arch/arm/mm.c | 2 +-
xen/arch/arm/p2m.c| 18 +-
xen/include/asm-arm/p2m.h | 4 ++--
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/ar
to avoid mixing machine frame with guest frame. Also drop the prefix start_.
Signed-off-by: Julien Grall
---
Changes in v4:
- Patch added
---
xen/arch/arm/mm.c | 2 +-
xen/arch/arm/p2m.c| 10 +-
xen/include/asm-arm/p2m.h | 4 ++--
3 files changed, 8 inserti
>>> On 28.06.16 at 15:59, wrote:
> For xenstored running in the same domain as the toolstack, sockets are
> less overhead than the shared memory ring, as no hypercalls are
> involved. There is also the unfortunate problem that one of the two
> linux devices for xenstored *still* causes deadlocks
Hi,
I had to modify some code in arch/x86/debug.c and noticed that Mukesh is
still the maintainer. IIRC he left Oracle quite a while ago, so my
e-mail was bounced by the server.
Do we have a new e-mail address for me? If not, does anyone plan to
maintain this code? Shall we mark the code as
Currently, accessing the I/O handlers does not require to take a lock
because new handlers are always added at the end of the array. In a
follow-up patch, this array will be sort to optimize the look up.
Given that most of the time the I/O handlers will not be modify,
using a spinlock will add con
On 6/28/16 11:27 AM, Jan Beulich wrote:
On 28.06.16 at 15:59, wrote:
>> For xenstored running in the same domain as the toolstack, sockets are
>> less overhead than the shared memory ring, as no hypercalls are
>> involved. There is also the unfortunate problem that one of the two
>> linux de
On 28/06/16 17:11, Jan Beulich wrote:
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -40,9 +40,20 @@ SECTIONS
>>> #if !defined(EFI)
>>>. = __XEN_VIRT_START;
>>>__image_base__ = .;
>>> +#else
>>> + . = __image_base__;
>>> #endif
>>>
>>> +#if 0
>>> +/*
>>> + * W
On 28/06/16 17:17, Julien Grall wrote:
> A variable containing a guest frame should be compared to INVALID_GFN
> and not INVALID_GFN.
>
> Signed-off-by: Julien Grall
Reviewed-by: Andrew Cooper
I suspect these (mis)uses predate my movement of INVALID_GFN from x86
paging code to common code.
___
On 28/06/16 17:31, Julien Grall wrote:
> Hi,
>
> I had to modify some code in arch/x86/debug.c and noticed that Mukesh
> is still the maintainer. IIRC he left Oracle quite a while ago, so my
> e-mail was bounced by the server.
>
> Do we have a new e-mail address for me? If not, does anyone plan to
It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
on the vCPU which crashed. This doesn't work very well for PVHVM guests as
we have a numb
HYPERVISOR_vcpu_op passes Linux's idea of vCPU id as a parameter while
Xen's idea is expected. In some cases these ideas diverge so we need to
do remapping.
There is an issue, however. PV guests do VCPUOP_is_up very early
(see xen_fill_possible_map() and xen_filter_cpu_maps()) when we don't have
p
Update cpuid.h header from xen hypervisor tree to get
XEN_HVM_CPUID_VCPU_ID_PRESENT definition.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/include/asm/xen/cpuid.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen
It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
on the vCPU which crashed. This doesn't work very well for PVHVM guests as
we have a numb
EVTCHNOP_bind_ipi and EVTCHNOP_bind_virq pass vCPU id as a parameter and
Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id
mapping to convert it from Linux's id.
Signed-off-by: Vitaly Kuznetsov
---
drivers/xen/events/events_base.c | 10 +-
1 file changed, 5 inser
On 28/06/16 18:43, Andrew Cooper wrote:
> On 28/06/16 17:17, Julien Grall wrote:
>> A variable containing a guest frame should be compared to INVALID_GFN
>> and not INVALID_GFN.
I think the text should be changed? I'd expect one 'G' being replaced
bay 'M'. :-)
Juergen
>>
>> Signed-off-by: Julie
EVTCHNOP_init_control has vCPU id as a parameter and Xen's idea of vCPU id
should be used. Use the newly introduced xen_vcpu_id mapping to convert
it from Linux's id.
Signed-off-by: Vitaly Kuznetsov
---
drivers/xen/events/events_fifo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
1 - 100 of 146 matches
Mail list logo
