> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, June 20, 2016 7:31 PM
>
> All host_msr_state accesses are solely on the owning CPU, and all
> guest_msr_state ones solely when the vCPU is current or being switched
> to. This, btw, is also in line with the use of find_first_set_bit()
On 6/22/2016 7:33 PM, George Dunlap wrote:
On 22/06/16 11:07, Yu Zhang wrote:
On 6/22/2016 5:47 PM, George Dunlap wrote:
On 22/06/16 10:29, Jan Beulich wrote:
On 22.06.16 at 11:16, wrote:
On 22/06/16 07:39, Jan Beulich wrote:
On 21.06.16 at 16:38, wrote:
On 21/06/16 10:47, Jan Beulich
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, June 20, 2016 7:32 PM
>
> ... by using dedicated initializers. Also add an ASSERT() to make sure
> unintentional addition of holes to the array gets noticed. Ditch
> MSR_INDEX_SIZE as redundant with VMX_MSR_COUNT.
>
> Signed-off-by: J
flight 96148 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96148/
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 22.06.16 at 20:24, wrote:
> On 06/22/2016 11:23 AM, Jan Beulich wrote:
> On 22.06.16 at 16:13, wrote:
>>> On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote:
>>> On 22.06.16 at 15:03, wrote:
> I've finally found what was causing long standing issue of not working
>>> On 23.06.16 at 10:32, wrote:
On 22.06.16 at 20:24, wrote:
>> Either method works, and I agree allowing DM to invoke this domctl is both
>> useful and not going to introduce problems. The getdomaininfo permission
>> will also need to be added to the device_model macro in xen.if.
>
> Wha
On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
> >>> On 22.06.16 at 20:24, wrote:
> > On 06/22/2016 11:23 AM, Jan Beulich wrote:
> > On 22.06.16 at 16:13, wrote:
> >>> On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote:
> >>> On 22.06.16 at 15:03, wrote:
> > I'
>>> On 23.06.16 at 10:57, wrote:
> On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
>> >>> On 22.06.16 at 20:24, wrote:
>> > On 06/22/2016 11:23 AM, Jan Beulich wrote:
>> > On 22.06.16 at 16:13, wrote:
>> >>> On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote:
>> >>>
On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
> >>> On 23.06.16 at 10:57, wrote:
> > On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
> >> >>> On 22.06.16 at 20:24, wrote:
> >> > On 06/22/2016 11:23 AM, Jan Beulich wrote:
> >> > On 22.06.16 at 16:13, wrote:
> >> >>
On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
> > >>> On 23.06.16 at 10:57, wrote:
> > > On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
> > >> >>> On 22.06.16 at 20:24, wrote:
> > >> > On 06
On 2016/5/31 18:35, Laszlo Ersek wrote:
> On 05/31/16 06:59, Shannon Zhao wrote:
>> > From: Shannon Zhao
>> >
>> > Add ACPI support for Virt Xen ARM and it gets the ACPI tables through
>> > Xen ARM multiboot protocol.
>> >
>> > Contributed-under: TianoCore Contribution Agreement 1.0
>> > Signe
On 2016/6/7 21:50, Julien Grall wrote:
>
> On 31/05/16 05:59, Shannon Zhao wrote:
>> +EFI_STATUS
>> +EFIAPI
>> +GetXenArmAcpiRsdp (
>> + OUT EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER **RsdpPtr
>> + )
>> +{
>> + VOID *Hob;
>> + EFI_ACPI_2_0_ROO
On 23/06/16 09:32, Jan Beulich wrote:
On 22.06.16 at 20:24, wrote:
>> On 06/22/2016 11:23 AM, Jan Beulich wrote:
>> On 22.06.16 at 16:13, wrote:
On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote:
On 22.06.16 at 15:03, wrote:
>> I've finally found what was cau
>>> On 23.06.16 at 11:18, wrote:
> On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
>> >>> On 23.06.16 at 10:57, wrote:
>> > On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
>> >> >>> On 22.06.16 at 20:24, wrote:
>> >> > On 06/22/2016 11:23 AM, Jan Beulich wrote:
>> >> >>
>>> On 23.06.16 at 11:23, wrote:
> On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki wrote:
>> On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
>> > >>> On 23.06.16 at 10:57, wrote:
>> > > On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
>> > >> I wonder
>>> On 23.06.16 at 11:44, wrote:
> On 23/06/16 09:32, Jan Beulich wrote:
>> I wonder what good the duplication of the returned domain ID does: I'm
>> tempted to remove the one in the command-specific structure. Does
>> anyone have insight into why it was done that way?
>
> This hypercall, and its
When page tables entries are set using xen_set_pte_init() during early
boot there is no page fault handler that could handle a fault when
performing an M2P lookup.
In 64 bit guests (usually dom0) early_ioremap() would fault in
xen_set_pte_init() because an M2P lookup faults because the MFN is in
M
On 21/06/16 19:26, Andrey Grodzovsky wrote:
> Current overlap check is evaluating to false a case where a filter field
> is fully contained (proper subset) of a r/w request.
> This change applies classical overlap check instead to include
> all the scenarios.
>
> More specifically, for (Hilscher G
On 23/06/16 06:12, Juergen Gross wrote:
> xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper
> bound of the loop setting non-kernel-image entries to zero should not
> exceed the size of level2_kernel_pgt.
Applied to for-linus-4.7b, thanks.
David
On 22/06/16 08:19, Jan Beulich wrote:
On 21.06.16 at 21:50, wrote:
>> On 20/06/16 12:29, Jan Beulich wrote:
>>> If we have the translation result available already, we should also use
>>> it here. In my tests with Linux guests this eliminates all calls to
>>> hvmemul_linear_to_phys() from the
On Tue, 21 Jun 2016, Julien Grall wrote:
> The correct acronym for a guest physical frame is gfn. Also use
> the recently introduced typesafe gfn/mfn to avoid mixing the two
> different kind of frame.
>
> Signed-off-by: Julien Grall
> Acked-by: Jan Beulich
Acked-by: Stefano Stabellini
> ---
On Tue, 21 Jun 2016, Julien Grall wrote:
> 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
Acke
Its contents is constant.
The ALIGN(32) is also dropped. On x86, there is nothing between it and a
larger alignment. On ARM, __init_end_efi is between the two, but its sole use
is to fill SizeOfRawData in the PE Section Table, and doesn't require any
specific alignment.
Signed-off-by: Andrew Co
On 22 June 2016 at 12:47, Stefano Stabellini wrote:
> The following changes since commit 6f1d2d1c5ad20d464705b17318cb7ca495f8078a:
>
> Merge remote-tracking branch 'remotes/stsquad/tags/pull-travis-20160621-1'
> into staging (2016-06-21 15:19:58 +0100)
>
> are available in the git repository at
On Tue, 21 Jun 2016, Julien Grall wrote:
> 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
On 20/06/16 12:57, Jan Beulich wrote:
> The former in an attempt to at least gradually support all simple data
> movement instructions. The latter just because it shares the opcode
> with the former.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
_
On 20/06/16 12:59, Jan Beulich wrote:
> Declare some variables to they can be used by multiple pieces of code,
> allowing some figure braces to be dropped (which don't align nicely
> when used inside of case labeled statements).
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
_
On 23/06/16 08:37, Yu Zhang wrote:
> On 6/22/2016 7:33 PM, George Dunlap wrote:
>> On 22/06/16 11:07, Yu Zhang wrote:
>>>
>>> On 6/22/2016 5:47 PM, George Dunlap wrote:
On 22/06/16 10:29, Jan Beulich wrote:
On 22.06.16 at 11:16, wrote:
>> On 22/06/16 07:39, Jan Beulich wrote:
>>>
flight 96146 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96146/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
94856
test-amd64-i3
On 20/06/16 12:58, Jan Beulich wrote:
> At least similar code should use similar exit mechanisms (return vs
> goto).
>
> Signed-off-by: Jan Beulich
> ---
> RFC reason: There are many more paths where we could return directly,
> avoiding the _put_fpu() and put_stub(). Otoh arguably the
On Wed, Jun 22, 2016 at 09:35:51AM -0600, Jan Beulich wrote:
> >>> On 20.06.16 at 18:30, wrote:
> > @@ -1582,6 +1583,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >
> > init_constructors();
> >
> > +warning_print();
> > +
> > console_endboot();
>
> What about an A
Hi Stefano,
On 23/06/16 11:20, Stefano Stabellini wrote:
On Tue, 21 Jun 2016, Julien Grall wrote:
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
On 22/06/16 17:16, Meng Xu wrote:
> On Wed, Jun 22, 2016 at 11:51 AM, George Dunlap
> wrote:
>> On Mon, May 16, 2016 at 12:54 AM, Tianyang Chen wrote:
>>> No functional change:
>>> -Various coding style fix
>>> -Added comments for UPDATE_LIMIT_SHIFT.
>>>
>>> Signed-off-by: Tianyang Chen
>>
>>
On 20/06/16 12:58, Jan Beulich wrote:
> @@ -3845,10 +3834,11 @@ x86_emulate(
> goto push;
> case 7:
> generate_exception_if(1, EXC_UD, -1);
> -default:
> -goto cannot_emulate;
> }
> break;
> +
> +default:
> +BUG();
On Wed, Jun 22, 2016 at 09:37:55AM -0600, Jan Beulich wrote:
> >>> On 20.06.16 at 18:30, wrote:
> > @@ -44,6 +44,14 @@ string_param("conswitch", opt_conswitch);
> > /* sync_console: force synchronous console output (useful for debugging).
> > */
> > static bool_t __initdata opt_sync_console;
>
On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
> >>> On 20.06.16 at 18:30, wrote:
> > @@ -97,9 +98,17 @@ boolean_param("hap", opt_hap_enabled);
> >
> > #ifndef opt_hvm_fep
> > /* Permit use of the Forced Emulation Prefix in HVM guests */
> > -bool_t opt_hvm_fep;
> > +bool_t __rea
Hello,
On 22/06/16 18:17, Julien Grall wrote:
On 22/06/16 17:35, Corneliu ZUZU wrote:
Julien,
Hello Corneliu,
I was trying to implement having HCR stored in arch_domain or arch_vcpu
as suggested above and I'm a bit confused about the code in
p2m_restore_state.
I'm hoping you can provide so
Hello,
On 23/06/16 06:49, Corneliu ZUZU wrote:
On 6/23/2016 8:31 AM, Corneliu ZUZU wrote:
On 6/22/2016 10:41 PM, Julien Grall wrote:
On 22/06/2016 20:37, Corneliu ZUZU wrote:
I've also realized that it's a bit complicated to avoid writing HCR
from
2 places.
That's because:
- p2m_restore_sta
flight 96157 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96157/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saver
On Thu, Jun 23, 2016 at 11:37:43AM +0100, Wei Liu wrote:
[...]
> The warning text (multiple lines) is added as one single string, which
> means we can't trivially add leading stars at the beginning of each
> line.
>
> I don't feel like arguing over how the text would look like, so if
> something l
On 23/06/16 12:17, Wei Liu wrote:
> On Thu, Jun 23, 2016 at 11:37:43AM +0100, Wei Liu wrote:
> [...]
>> The warning text (multiple lines) is added as one single string, which
>> means we can't trivially add leading stars at the beginning of each
>> line.
>>
>> I don't feel like arguing over how the
flight 96150 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96150/
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
Folks,
do you guys want to hold a Developer Meeting on Aug 24th (before Dev Summit). I
do have space to do this, but last year's was very poorly attended. If you
could get back to me with an opinion, that would help hugely. Alternatively it
would also be possible to use the space for more focus
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
---
Changes since v1:
* move the codes into ArmVirtPkg
* use FdtClient
* don
On 23/06/16 12:33, Lars Kurth wrote:
> Folks,
>
> do you guys want to hold a Developer Meeting on Aug 24th (before Dev Summit).
> I do have space to do this, but last year's was very poorly attended. If you
> could get back to me with an opinion, that would help hugely. Alternatively
> it would
Hi Andrew,
On 21/06/16 17:59, Andrew Cooper wrote:
There is no reason for any of it to be modified. Additionally, link
.init.setup beside the other constant .init data.
While editing this area, correct the types used in the extern
declarations for __setup_start and __setup_end to match the typ
Hi Andrew,
On 21/06/16 17:59, Andrew Cooper wrote:
Its contents is constant, and only requires pointer alignment, so move it
adacent to .init.setup.
Signed-off-by: Andrew Cooper
Acked-by: Julien Grall
Regards,
--
Julien Grall
___
Xen-devel mail
Hi Andrew,
On 23/06/16 11:12, Andrew Cooper wrote:
Its contents is constant.
The ALIGN(32) is also dropped. On x86, there is nothing between it and a
larger alignment. On ARM, __init_end_efi is between the two, but its sole use
is to fill SizeOfRawData in the PE Section Table, and doesn't req
On Thu, Jun 23, 2016 at 12:33:00PM +0100, Lars Kurth wrote:
> Folks,
>
> do you guys want to hold a Developer Meeting on Aug 24th (before Dev
> Summit). I do have space to do this, but last year's was very poorly
> attended. If you could get back to me with an opinion, that would help
> hugely. Al
On 06/23/2016 05:51 AM, David Vrabel wrote:
When page tables entries are set using xen_set_pte_init() during early
boot there is no page fault handler that could handle a fault when
performing an M2P lookup.
In 64 bit guests (usually dom0) early_ioremap() would fault in
xen_set_pte_init() beca
On 23/06/16 11:51, David Vrabel wrote:
> When page tables entries are set using xen_set_pte_init() during early
> boot there is no page fault handler that could handle a fault when
> performing an M2P lookup.
>
> In 64 bit guests (usually dom0) early_ioremap() would fault in
> xen_set_pte_init() b
>>> On 23.06.16 at 13:17, wrote:
> On Thu, Jun 23, 2016 at 11:37:43AM +0100, Wei Liu wrote:
> [...]
>> The warning text (multiple lines) is added as one single string, which
>> means we can't trivially add leading stars at the beginning of each
>> line.
>>
>> I don't feel like arguing over how th
All,
I am pleased to announce the release of Xen 4.6.3. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.6
(tag RELEASE-4.6.3) or from the XenProject download page
http://www.xenproject.org/downloads/xen-archives/xen-4
>>> On 23.06.16 at 12:50, wrote:
> On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
>> >>> On 20.06.16 at 18:30, wrote:
>> > @@ -97,9 +98,17 @@ boolean_param("hap", opt_hap_enabled);
>> >
>> > #ifndef opt_hvm_fep
>> > /* Permit use of the Forced Emulation Prefix in HVM guests */
>
>>> On 23.06.16 at 12:36, wrote:
> On 20/06/16 12:58, Jan Beulich wrote:
>> At least similar code should use similar exit mechanisms (return vs
>> goto).
>>
>> Signed-off-by: Jan Beulich
>> ---
>> RFC reason: There are many more paths where we could return directly,
>> avoiding the _p
>>> On 23.06.16 at 12:44, wrote:
> On 20/06/16 12:58, Jan Beulich wrote:
>> @@ -3845,10 +3834,11 @@ x86_emulate(
>> goto push;
>> case 7:
>> generate_exception_if(1, EXC_UD, -1);
>> -default:
>> -goto cannot_emulate;
>> }
>>
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Tuesday, May 24, 2016 10:02 PM
> To: Wu, Feng ; Jan Beulich
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin
> ; xen-devel@lists.xen.org; konrad.w...@oracle.com;
> k...@xen.org
> On 23 Jun 2016, at 12:39, George Dunlap wrote:
>
> On 23/06/16 12:33, Lars Kurth wrote:
>> Folks,
>>
>> do you guys want to hold a Developer Meeting on Aug 24th (before Dev
>> Summit). I do have space to do this, but last year's was very poorly
>> attended. If you could get back to me with
On Thu, Jun 23, 2016 at 06:20:38AM -0600, Jan Beulich wrote:
> >>> On 23.06.16 at 12:50, wrote:
> > On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
> >> >>> On 20.06.16 at 18:30, wrote:
> >> > @@ -97,9 +98,17 @@ boolean_param("hap", opt_hap_enabled);
> >> >
> >> > #ifndef opt_hvm_
On 23/06/16 13:44, Wei Liu wrote:
> On Thu, Jun 23, 2016 at 06:20:38AM -0600, Jan Beulich wrote:
> On 23.06.16 at 12:50, wrote:
>>> On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
>>> On 20.06.16 at 18:30, wrote:
> @@ -97,9 +98,17 @@ boolean_param("hap", opt_hap_enabled);
On Thu, Jun 23, 2016 at 01:48:35PM +0100, Andrew Cooper wrote:
> On 23/06/16 13:44, Wei Liu wrote:
> > On Thu, Jun 23, 2016 at 06:20:38AM -0600, Jan Beulich wrote:
> > On 23.06.16 at 12:50, wrote:
> >>> On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
> >>> On 20.06.16 at 18:30
Dear Community Members,
I’m pleased to announce the release of Xen Project Hypervisor 4.7 and Xen
Project Hypervisor 4.6.3.
Best Regards
Lars, Wei, Jan
= Xen Project Hypervisor 4.7 =
This new release focuses on improving code quality, security hardening,
security features, live migration supp
>>> On 23.06.16 at 14:44, wrote:
> On Thu, Jun 23, 2016 at 06:20:38AM -0600, Jan Beulich wrote:
>> >>> On 23.06.16 at 12:50, wrote:
>> > On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
>> >> >>> On 20.06.16 at 18:30, wrote:
>> >> > @@ -97,9 +98,17 @@ boolean_param("hap", opt_hap_ena
On 23/06/16 13:13, Juergen Gross wrote:
> On 23/06/16 11:51, David Vrabel wrote:
>> When page tables entries are set using xen_set_pte_init() during early
>> boot there is no page fault handler that could handle a fault when
>> performing an M2P lookup.
>>
>> In 64 bit guests (usually dom0) early_i
On Thu, 23 Jun 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 23/06/16 11:20, Stefano Stabellini wrote:
> > On Tue, 21 Jun 2016, Julien Grall wrote:
> > > The x86 version of the function xenmem_add_to_physmap_one contains
> > > variable name gpfn and gfn which make the code very confusing.
> > > I
flight 96151 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96151/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 3 host-install(3) broken REGR. vs. 96125
test-amd64-amd64-xl-
On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
> >>> On 23.06.16 at 11:23, wrote:
> > On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki wrote:
> >> On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
> >> > >>> On 23.06.16 at 10:57, wrote:
> >> > > On Thu
On 23/06/16 15:06, David Vrabel wrote:
> On 23/06/16 13:13, Juergen Gross wrote:
>> On 23/06/16 11:51, David Vrabel wrote:
>>> When page tables entries are set using xen_set_pte_init() during early
>>> boot there is no page fault handler that could handle a fault when
>>> performing an M2P lookup.
On 23/06/16 14:06, Stefano Stabellini wrote:
On Thu, 23 Jun 2016, Julien Grall wrote:
On 23/06/16 11:20, Stefano Stabellini wrote:
On Tue, 21 Jun 2016, Julien Grall wrote:
I think there is a possible loss of information here: xen_pfn_t is
always uint64_t on both ARM and ARM64, while gfn_t is un
On 23/06/16 14:27, Juergen Gross wrote:
> On 23/06/16 15:06, David Vrabel wrote:
>> On 23/06/16 13:13, Juergen Gross wrote:
>>> On 23/06/16 11:51, David Vrabel wrote:
When page tables entries are set using xen_set_pte_init() during early
boot there is no page fault handler that could hand
On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> It only constructs the ACPI tables for 64-bit ARM DomU when user enables
> acpi because 32-bit DomU doesn't support ACPI.
>
> Signed-off-by: Shannon Zhao
> ---
> tools/libxl/Makefile | 4 +++
> tools/libxl/libxl_arm.c
On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a configuration option for ARM DomU so that user can deicde to use
> ACPI or not. This option is defaultly false.
>
> Signed-off-by: Shannon Zhao
> ---
> tools/libxl/libxl_arm.c | 3 +++
> tools/libxl/libxl_types.idl
On Thu, 23 Jun 2016, Julien Grall wrote:
> On 23/06/16 14:06, Stefano Stabellini wrote:
> > On Thu, 23 Jun 2016, Julien Grall wrote:
> > > On 23/06/16 11:20, Stefano Stabellini wrote:
> > > > On Tue, 21 Jun 2016, Julien Grall wrote:
> > > > I think there is a possible loss of information here: xen_
On 23/06/16 15:37, David Vrabel wrote:
> On 23/06/16 14:27, Juergen Gross wrote:
>> On 23/06/16 15:06, David Vrabel wrote:
>>> On 23/06/16 13:13, Juergen Gross wrote:
On 23/06/16 11:51, David Vrabel wrote:
> When page tables entries are set using xen_set_pte_init() during early
> boot
On 23 June 2016 at 13:31, 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
> ---
> Changes s
On Tue, 21 Jun 2016, Julien Grall wrote:
> 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
On Tue, 21 Jun 2016, Julien Grall wrote:
> 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 v2:
> - Remove extra pair
On Tue, 21 Jun 2016, Julien Grall wrote:
> 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:
On 23/06/16 15:05, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index aa4e774..47cb383 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1245,27 +1245,27 @@ int unmap_regions_rw_cache(struct domain *d,
}
int map_mmio_regions(struct domain *d,
-
On 23/06/16 14:25, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
> On 23.06.16 at 11:23, wrote:
>>> On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki wrote:
On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
>
On Tue, 21 Jun 2016, Julien Grall wrote:
> 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
On Thu, 23 Jun 2016, Julien Grall wrote:
> On 23/06/16 15:05, Stefano Stabellini wrote:
> > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > index aa4e774..47cb383 100644
> > > --- a/xen/arch/arm/p2m.c
> > > +++ b/xen/arch/arm/p2m.c
> > > @@ -1245,27 +1245,27 @@ int unmap_regions_rw_cac
On 23/06/16 10:50, Jan Beulich wrote:
On 23.06.16 at 11:44, wrote:
>> On 23/06/16 09:32, Jan Beulich wrote:
>>> I wonder what good the duplication of the returned domain ID does: I'm
>>> tempted to remove the one in the command-specific structure. Does
>>> anyone have insight into why it was
flight 96152 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96152/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927
build-i
On 2016年06月23日 21:37, Stefano Stabellini wrote:
> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>> +
>> +if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
>> +LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
>> +state->config.acpi = false;
>
> Shouldn't we return h
On Thu, 23 Jun 2016, Shannon Zhao wrote:
> On 2016年06月23日 21:37, Stefano Stabellini wrote:
> > On Thu, 23 Jun 2016, Shannon Zhao wrote:
> >> +
> >> +if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
> >> +LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
> >> +s
On 2016年06月23日 21:42, Ard Biesheuvel wrote:
> On 23 June 2016 at 13:31, 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
On 06/23/2016 04:39 AM, Jan Beulich wrote:
On 23.06.16 at 10:32, wrote:
On 22.06.16 at 20:24, wrote:
Either method works, and I agree allowing DM to invoke this domctl is both
useful and not going to introduce problems. The getdomaininfo permission
will also need to be added to the device_mo
On 2016年06月23日 21:39, Stefano Stabellini wrote:
> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>> > From: Shannon Zhao
>> >
>> > Add a configuration option for ARM DomU so that user can deicde to use
>> > ACPI or not. This option is defaultly false.
>> >
>> > Signed-off-by: Shannon Zhao
>> > ---
>>
On 06/22/2016 01:15 PM, Anthony PERARD wrote:
> ... and load BIOS/UEFI firmware into guest memory.
>
> This adds a new firmware module, system_firmware_module. It is loaded in
> the guest memory and final location is provided to hvmloader via the
> hvm_start_info struct.
>
> This patch create the h
>>> On 23.06.16 at 15:25, wrote:
> On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
>> >>> On 23.06.16 at 11:23, wrote:
>> > On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki wrote:
>> >> On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
>> >> > >>> On 23
On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> It uses static DSDT table like the way x86 uses. Currently the DSDT
> table only contains processor device objects and it generates the
> maximal objects which so far is 128.
>
> Signed-off-by: Shannon Zhao
> ---
> tools/libxl/M
On 20/06/16 13:52, Jan Beulich wrote:
> +/*
> + * Note that this value is effectively part of the ABI, even if we don't need
> + * to make it a formal part of it. Hence this value may only be changed if
> + * accompanied by a suitable interface version increase.
> + */
> +#define HVMCTL_iter_shift
Hi,
> How could xen_ram_init() find out if the value of max-ram-below-4g is
> the default or if a user have set it? Is there another way we could fix
> this?
Attached patch should fix it. Patch survived a quick smoke test on kvm
so far, need to do some more testing tomorrow. Can you give it a
On 23/06/16 15:15, Stefano Stabellini wrote:
On Thu, 23 Jun 2016, Julien Grall wrote:
On 23/06/16 15:05, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index aa4e774..47cb383 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1245,27 +1245,27 @@ int unm
On Thu, Jun 23, 2016 at 03:12:04PM +0100, Andrew Cooper wrote:
> On 23/06/16 14:25, Marek Marczykowski-Górecki wrote:
> > On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
> > On 23.06.16 at 11:23, wrote:
> >>> On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki
>
On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Construct GTDT table with the interrupt information of timers.
>
> Signed-off-by: Shannon Zhao
> ---
> tools/libxl/libxl_arm_acpi.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/tools/li
On 06/23/2016 09:25 AM, Marek Marczykowski-Górecki wrote:
[...]
Ok, after drawing a flowchart of the control in this function after your
change, on a piece of paper, this case looks fine. But depending on how
the domain was found (explicit loop or rcu_lock_domain_by_id), different
locks are held,
On 22/06/16 16:58, Julien Grall wrote:
On 21/06/16 11:15, Dirk Behme wrote:
+printk("Failed to remember the clock node of %s\n", path);
+printk("Use the Linux kernel command
'clk_ignore_unused'\n");
+return 0;
I don't think this is tolerable. We need to fix
On 23/06/16 15:59, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 23, 2016 at 03:12:04PM +0100, Andrew Cooper wrote:
>> On 23/06/16 14:25, Marek Marczykowski-Górecki wrote:
>>> On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
>>> On 23.06.16 at 11:23, wrote:
> On Thu, Jun 23,
1 - 100 of 185 matches
Mail list logo
