>>> On 29.03.16 at 11:30, wrote:
> @@ -806,7 +808,8 @@ static int viridian_save_vcpu_ctxt(struct domain *d,
> hvm_domain_context_t *h)
> for_each_vcpu( d, v ) {
> struct hvm_viridian_vcpu_context ctxt;
>
> -ctxt.apic_assist = v->arch.hvm_vcpu.viridian.apic_assist.msr.raw;
On Tue, Mar 29, 2016 at 08:35:34AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 09:29, wrote:
> > static void *get_xsave_addr(struct xsave_struct *xsave,
> > -unsigned int xfeature_idx)
> > +const uint16_t *comp_offsets,
> > +unsig
On Tue, Mar 29, 2016 at 09:00:38AM -0600, Jan Beulich wrote:
> >
> > xsaves will be used until supervised state is instroduced in hypervisor.
>
> "xsaves will not be used ... introduced ..." I suppose?
Thanks
>
> > @@ -223,13 +223,15 @@ void compress_xsave_states(struct vcpu *v, const void
> >
flight 87872 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87872/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 10 guest-start fail REGR. vs. 86454
test-amd64-i386-xl-
On 29/03/16 12:35, Juergen Gross wrote:
> On 29/03/16 11:45, George Dunlap wrote:
>> On Fri, Mar 25, 2016 at 6:09 AM, Juergen Gross wrote:
>>> On 24/03/16 21:07, Wei Liu wrote:
On Fri, Mar 18, 2016 at 09:24:26AM +0100, Juergen Gross wrote:
> On 17/03/16 17:55, George Dunlap wrote:
>>
On 3/29/16 2:37 PM, sabiya wrote:
Sabiya,
Please have a look at:
http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
And review the sections titled "Signing off a patch" and "Write a good
description for each patch". Basically you need to provide a short
summary and then a newline and
On March 30, 2016 10:28am, Xu, Quan wrote:
> If this is still the correct one, could you help me send out the correct one?
>
Sorry, a typo:
If this is still _not_ the correct one, could you help me send out the correct
one?
Quan
___
Xen-devel mailing
On March 29, 2016 3:21pm, wrote:
> >>> On 28.03.16 at 05:33, wrote:
> > On March 18, 2016 1:15am, wrote:
> >> >>> On 17.03.16 at 07:54, wrote:
> >> > --- a/xen/common/grant_table.c
> >> > +++ b/xen/common/grant_table.c
> >> > @@ -932,8 +932,9 @@ __gnttab_map_grant_ref(
> >> > {
> >
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Wednesday, March 30, 2016 12:58 AM
> To: Konrad Rzeszutek Wilk
> Cc: Hao, Xudong ; wei.l...@citrix.com;
> samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com; xen-
> de...@lists.xen.org
> Subject: Re: [Xen
flight 87856 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87856/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken in 87395 REGR. vs. 66399
build-amd64-rumpuserxen
On Tue, Mar 29, 2016 at 6:07 PM, Toshi Kani wrote:
> On Tue, 2016-03-29 at 16:43 -0700, Luis R. Rodriguez wrote:
>> I meant to ask about the case where the option the lets a user go in a
>> muck with BIOS settings to disable MTRR e xists and the user disables
>> MTRR. What would happen for fan con
On Tue, 2016-03-29 at 16:43 -0700, Luis R. Rodriguez wrote:
> On Tue, Mar 29, 2016 at 5:16 PM, Toshi Kani wrote:
> > On Tue, 2016-03-29 at 15:12 -0700, Luis R. Rodriguez wrote:
> > > On Tue, Mar 29, 2016 at 2:46 PM, Toshi Kani
> > > wrote:
> > > > On Tue, 2016-03-29 at 10:14 -0700, Luis R. Rodrig
On Tue, Mar 29, 2016 at 5:16 PM, Toshi Kani wrote:
> On Tue, 2016-03-29 at 15:12 -0700, Luis R. Rodriguez wrote:
>> On Tue, Mar 29, 2016 at 2:46 PM, Toshi Kani wrote:
>> > On Tue, 2016-03-29 at 10:14 -0700, Luis R. Rodriguez wrote:
>> > > On Fri, Mar 18, 2016 at 2:35 PM, Toshi Kani
>> > > wrote:
On Tue, 2016-03-29 at 15:12 -0700, Luis R. Rodriguez wrote:
> On Tue, Mar 29, 2016 at 2:46 PM, Toshi Kani wrote:
> > On Tue, 2016-03-29 at 10:14 -0700, Luis R. Rodriguez wrote:
> > > On Fri, Mar 18, 2016 at 2:35 PM, Toshi Kani
> > > wrote:
:
> > >
> > > Do we really need UC for the fan?
> >
>
On Tue, Mar 29, 2016 at 04:14:41PM -0600, Toshi Kani wrote:
> On Tue, 2016-03-29 at 10:22 -0700, Luis R. Rodriguez wrote:
> > On Thu, Mar 17, 2016 at 11:56 AM, Luis R. Rodriguez
> > wrote:
> > > On Thu, Mar 17, 2016 at 11:13:03AM +, David Vrabel wrote:
> > > > On 16/03/16 20:08, Luis R. Rodrig
sorry, i think i got your point. i don't know exactly which menuentry in grub2
refer to xen.gz. furthermore i deleted xen.gz when i was compiled and installed
xen, because it issue an error (warning) which didn't let update-grub to be
successful. after studying forums, i understood to delete it
On Tue, Mar 29, 2016 at 2:46 PM, Toshi Kani wrote:
> On Tue, 2016-03-29 at 10:14 -0700, Luis R. Rodriguez wrote:
>> On Fri, Mar 18, 2016 at 2:35 PM, Toshi Kani wrote:
>> > On Thu, 2016-03-17 at 17:06 -0700, Luis R. Rodriguez wrote:
>> > > On Mar 17, 2016 2:04 PM, "Toshi Kani" wrote:
>> > > >
>
flight 87832 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87832/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
test-amd64-amd64-xl
flight 87926 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87926/
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 Tue, 2016-03-29 at 10:22 -0700, Luis R. Rodriguez wrote:
> On Thu, Mar 17, 2016 at 11:56 AM, Luis R. Rodriguez
> wrote:
> > On Thu, Mar 17, 2016 at 11:13:03AM +, David Vrabel wrote:
> > > On 16/03/16 20:08, Luis R. Rodriguez wrote:
> > > > Toshi noted a while ago as well that if BIOS/firmwa
Hi Julian,
Thanks for the reply.
On Wed, Mar 30, 2016 at 12:31 AM, Julien Grall wrote:
> Hello Dushyant,
>
> On 24/03/16 11:05, Dushyant Behl wrote:
>>
>> I was not receiving the dom0 logs because of a mistake in my dom0
>> bootargs. In the bootargs the option
>> for earlyprintk was not marked a
On Tue, 2016-03-29 at 10:14 -0700, Luis R. Rodriguez wrote:
> On Fri, Mar 18, 2016 at 2:35 PM, Toshi Kani wrote:
> > On Thu, 2016-03-17 at 17:06 -0700, Luis R. Rodriguez wrote:
> > > On Mar 17, 2016 2:04 PM, "Toshi Kani" wrote:
> > > >
:
> >
> > I do not see any issue for Xen, but sure, we can
On Tue, Mar 29, 2016 at 03:36:12AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, wrote:
> > +struct xen_sysctl_xsplice_list {
> > +uint32_t version; /* OUT: Hypervisor stamps
> > value.
> > + If varies between calls
flight 87844 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87844/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
On 3/24/16 9:31 AM, Jan Beulich wrote:
> They're not really useful past the building stage and only needlessly
> increase binary file sizes.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -50,6 +50,7 @@ ALL_OBJS-$(CONFIG_X86) += $(BASEDIR)/c
> CFLAGS += -nostd
Hi,
I need to know what happens while a cpu which is running a vcpu, suddenly crash
or down? I mean have xen any plane for such a situation?
in other word what will happen for a vcpu which it's related cpu get down
suddenly (i mean for vcpu which has that crashed cpu's affinity)?
Thanks and reg
> On 29 Mar 2016, at 17:38, Wei Liu wrote:
>
> On Tue, Mar 29, 2016 at 10:08:30AM +0100, Jonathan Davies wrote:
>> On Thu, Mar 24, 2016 at 07:57:30PM -0400, Boris Ostrovsky wrote:
>>> On 03/24/2016 06:49 PM, Andrew Cooper wrote:
On 24/03/2016 22:22, Boris Ostrovsky wrote:
> On 03/17/201
---
tools/console/client/main.c | 26 --
tools/libxl/libxl.c | 15 ++-
tools/libxl/libxl.h | 23 ---
tools/libxl/xl_cmdimpl.c| 30 --
tools/libxl/xl_cmdtable.c | 5 +++--
5 files changed, 81
On 24/03/16 12:20, 신정섭 wrote:
HI I have a question Question about '/proc/interrupts' on Xen ARM.
Hello,
Please avoid to attach image on the mailing list.
I'm running Xen ARM 4.4.2 on Arndale Board.
I Attached a Image that is is result of 'cat /proc/interrupts' DomainU on Xen
ARM.
I know th
Hello Dushyant,
On 24/03/16 11:05, Dushyant Behl wrote:
I was not receiving the dom0 logs because of a mistake in my dom0
bootargs. In the bootargs the option
for earlyprintk was not marked as Xen. Now that I've enabled it I'm
able to see some bootlog from dom0 linux.
At least now I'm able to f
On 23/03/16 17:24, Dirk Behme wrote:
Hi,
Hello Dirk,
Sorry for the late answer.
trying to bring up Xen on a new ARMv8 64-bit Cortex A57 eval board, I
get [1] and then its hanging there.
The logs look normal.
Do you know where the kernel get stuck? You can press CTRL-a 3 times to
get acce
flight 87912 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87912/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 87376
Tests which di
Greg, please see below - this is probably more for you...
On 03/29/2016 04:56 AM, Steven Haigh wrote:
>
> Interestingly enough, this just happened again - but on a different
> virtual machine. I'm starting to wonder if this may have something to do
> with the uptime of the machine - as the system
flight 87830 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87830/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 60684
test-amd64
On 03/29/2016 06:39 PM, Konrad Rzeszutek Wilk wrote:
>> static void tsc_check_slave(void *unused)
>> @@ -1437,6 +1515,20 @@ static int __init verify_tsc_reliability(void)
>> }
>> }
>>
>> +if ( !strcmp(opt_clocksource, "tsc") )
>
> Pls also update xen-command-line.markdown
>
On Mon, Mar 28, 2016 at 06:00:33PM +0100, Michael Young wrote:
> I get a crash on boot with my Fedora xen-4.6.1-3.fc24 packages. This seems
> to be related to how it is compiled because the same code compiled under
> Fedora 23 works. The boot logs are attached. The address mentioned in the
> crash
On 30/03/2016 1:14 AM, Boris Ostrovsky wrote:
> On 03/29/2016 04:56 AM, Steven Haigh wrote:
>>
>> Interestingly enough, this just happened again - but on a different
>> virtual machine. I'm starting to wonder if this may have something to do
>> with the uptime of the machine - as the system that th
> static void tsc_check_slave(void *unused)
> @@ -1437,6 +1515,20 @@ static int __init verify_tsc_reliability(void)
> }
> }
>
> +if ( !strcmp(opt_clocksource, "tsc") )
Pls also update xen-command-line.markdown
> +{
> +if ( try_platform_timer(&plt_tsc) > 0 )
> +
On Tue, 2016-03-29 at 13:13 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 29, 2016 at 06:59:15PM +0200, Dario Faggioli wrote:
> > On Fri, 2016-03-25 at 13:07 -0500, Chong Li wrote:
> > > Ok. I've already fixed all problems pointed out by George and
> > > Jan.
> > >
> > > Dario and Meng, do you
On Tue, Mar 29, 2016 at 06:21:40AM -0600, Jan Beulich wrote:
> REST maintainers,
>
> may I please ask for acks or otherwise on
> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg03193.html
Could you resend the ones you want in 4.7 pls?
I recall Reviewing one of them - and one of th
On Tue, Mar 29, 2016 at 11:01:16AM +0100, Stefano Stabellini wrote:
> Not my full time job anymore, but still maintaining it.
Applied to for-linux-4.6.
Congrats on your new job!
>
> Signed-off-by: Stefano Stabellini
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 32bafda..049aa1d 100644
> -
On Thu, Mar 17, 2016 at 11:56 AM, Luis R. Rodriguez wrote:
> On Thu, Mar 17, 2016 at 11:13:03AM +, David Vrabel wrote:
>> On 16/03/16 20:08, Luis R. Rodriguez wrote:
>> > Toshi noted a while ago as well that if BIOS/firmware enables MTRR but
>> > the kernel does not have it enabled one issue m
On 3/29/16 6:44 AM, George Dunlap wrote:
> On Mon, Mar 28, 2016 at 4:01 PM, Doug Goldstein wrote:
>> On 3/16/16 2:14 PM, Doug Goldstein wrote:
>>> On 3/8/16 10:50 AM, Wei Liu wrote:
On Tue, Mar 08, 2016 at 10:34:42AM -0600, Doug Goldstein wrote:
> On 3/8/16 9:38 AM, Wei Liu wrote:
>>
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
scan this to get the UEFI information.
CC: Rob Herring
Signed-off-by: Shannon Zhao
Acked-by: Rob Herring
Reviewed-by: Stefano Stabellini
---
Documentation/devicetree
On Fri, Mar 18, 2016 at 2:35 PM, Toshi Kani wrote:
> On Thu, 2016-03-17 at 17:06 -0700, Luis R. Rodriguez wrote:
>> On Mar 17, 2016 2:04 PM, "Toshi Kani" wrote:
>> >
>> > On Wed, 2016-03-16 at 00:29 +0100, Luis R. Rodriguez wrote:
>> > > On Tue, Mar 15, 2016 at 05:48:44PM -0600, Toshi Kani wrote:
On Tue, Mar 29, 2016 at 06:59:15PM +0200, Dario Faggioli wrote:
> On Fri, 2016-03-25 at 13:07 -0500, Chong Li wrote:
> > Ok. I've already fixed all problems pointed out by George and Jan.
> >
> > Dario and Meng, do you have any other comments on this patch?
> >
> Ok, I've looked at the patch and
On Tue, Mar 29, 2016 at 05:14:42PM +0100, Wei Liu wrote:
> On Tue, Mar 29, 2016 at 04:55:23PM +0100, Paul Durrant wrote:
> > Commit 78c5f59e "x86/hvm/viridian: save APIC assist vector" changed
> > the name of a field in the viridian vcpu save record. Unfortunately this
> > record has a decode funct
On Fri, 2016-03-18 at 16:26 -0500, Chong Li wrote:
> Add xc_sched_rtds_vcpu_get/set functions to interact with
> Xen to get/set a domain's per-VCPU parameters.
>
> Signed-off-by: Chong Li
> Signed-off-by: Meng Xu
> Signed-off-by: Sisu Xi
>
> ---
> Changes on PATCH v6:
> 1) Resolve some coding
On Wed, Mar 16, 2016 at 1:20 PM, Luis R. Rodriguez wrote:
> On Thu, Nov 05, 2015 at 11:43:59AM -0800, Luis R. Rodriguez wrote:
>> On Thu, Nov 5, 2015 at 11:14 AM, Yinghai Lu wrote:
>> > On Mon, Sep 14, 2015 at 7:46 AM, Stuart Hayes
>> > wrote:
>> >>
>> >> Booting with 'disable_mtrr_cleanup' wor
flight 87899 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87899/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 87376
Tests which di
On Fri, 2016-03-25 at 13:07 -0500, Chong Li wrote:
> Ok. I've already fixed all problems pointed out by George and Jan.
>
> Dario and Meng, do you have any other comments on this patch?
>
Ok, I've looked at the patch and no, I don't have any further comments
on this patch (and it looks to me you
On Mon, Mar 28, 2016 at 09:21:14AM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 28, 2016 at 02:03:35AM +, Hao, Xudong wrote:
> > > -Original Message-
> > > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> > > Konrad
> > > Rzeszutek Wilk
> > > Sent: Saturday,
Hi everyone,
as you may know, the project has a test lab that tests hypervisor changes
against different Server Hardware. Unfortunately, the project can only support
off-the-shelf ARM server hardware in the test lab and thus our automated test
coverage for various ARM hardware is not yet that g
On Tue, Mar 29, 2016 at 10:08:30AM +0100, Jonathan Davies wrote:
> On Thu, Mar 24, 2016 at 07:57:30PM -0400, Boris Ostrovsky wrote:
> > On 03/24/2016 06:49 PM, Andrew Cooper wrote:
> > >On 24/03/2016 22:22, Boris Ostrovsky wrote:
> > >>On 03/17/2016 01:51 PM, Jonathan Davies wrote:
> > >>>Encapsula
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
When booting with ACPI, it could get the event-channel irq through
The kernel will always get the event-channel IRQ through
HVM_PARAM_CALLBACK_IRQ.
So I would say: ", the kernel will get the event-channel..."
HVM_PARAM_CALLBACK_IRQ.
Sign
On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote:
> On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> > When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
> > a /hypervisor node in DT. So check if it needs to enable ACPI.
> >
> > Signed-off-by: Shannon
Hi Shannon,
On 24/03/16 14:44, Shannon Zhao wrote:
Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
refer to 4K pages.
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
---
drivers/xen/xlate
Hi Jan,
On 29/03/16 08:12, Jan Beulich wrote:
On 25.03.16 at 14:48, wrote:
These patches are Part 4 (and last part) of the previous patch set I
sent which adds ACPI support for arm64 on Xen[1]. Split them as an
individual set for convenient reviewing.
These patches create UEFI and ACPI tables
Hi Shannon,
On 25/03/16 13:48, Shannon Zhao wrote:
Add ACPI support on arm64 xen hypervisor. Enable EFI support on ARM.
Cc: Jan Beulich
Signed-off-by: Shannon Zhao
Acked-by: Jan Beulich
Reviewed-by: Stefano Stabellini
Acked-by: Julien Grall
Regards,
--
Julien Grall
___
On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
> a /hypervisor node in DT. So check if it needs to enable ACPI.
>
> Signed-off-by: Shannon Zhao
> Reviewed-by: Stefano Stabellini
> Acked-by: Hanjun Guo
> ---
Hi Shannon,
On 25/03/16 13:48, Shannon Zhao wrote:
Store the event-channel interrupt number and flag in HVM parameter
HVM_PARAM_CALLBACK_IRQ. Then Dom0 could get it through hypercall
HVMOP_get_param.
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
Acked-by: Julien Grall
Regard
Hi Shannon,
On 25/03/16 13:48, Shannon Zhao wrote:
This new delivery type which is for ARM shares the same value with
HVM_PARAM_CALLBACK_TYPE_VECTOR which is for x86.
val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and
bit 9 stands the i
flight 87831 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87831/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 13 guest-sav
On Tue, Mar 29, 2016 at 04:55:23PM +0100, Paul Durrant wrote:
> Commit 78c5f59e "x86/hvm/viridian: save APIC assist vector" changed
> the name of a field in the viridian vcpu save record. Unfortunately this
> record has a decode function in xen-hvmctx and so it no longer builds.
>
> This patch fix
Hi Shannon,
On 25/03/16 13:48, Shannon Zhao wrote:
Add a new member in gic_hw_operations which is used to deny Dom0 access
to GIC regions.
Signed-off-by: Shannon Zhao
Acked-by: Julien Grall
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xe
Hi Shannon,
On 25/03/16 13:48, Shannon Zhao wrote:
Interrupt information is described in DSDT and is not available at the
time of booting. Check if the interrupt is permitted to access and set
the interrupt type, route it to guest dynamically only for SPI
and Dom0.
Signed-off-by: Parth Dixit
S
Hi Shannon,
On 25/03/16 13:48, Shannon Zhao wrote:
Allow DOM0 to use all SPIs but the ones used by Xen. Then when Dom0
configures the interrupt, it could set the interrupt type and route it
to Dom0.
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
Acked-by: Julien Grall
Regards
Hi Shannon,
On 25/03/16 13:48, Shannon Zhao wrote:
Create a DT for Dom0 for ACPI-case only. DT contains minimal required
informations such as Dom0 bootargs, initrd, efi description table and
NIT: informations/information/
address of uefi memory table.
Also document this device tree bindings
Commit 78c5f59e "x86/hvm/viridian: save APIC assist vector" changed
the name of a field in the viridian vcpu save record. Unfortunately this
record has a decode function in xen-hvmctx and so it no longer builds.
This patch fixes the field name in xen-hvmctx and also adds a decode of
the additional
On Sat, Mar 26, 2016 at 12:46 PM, Holger Schramm wrote:
> Hi there,
>
> i receive a build error at rombios.c and etherboot not declared. I have
> no idea how to fix this.
>
> One thing i stumbled is this commit:
>
> http://xenbits.xen.org/gitweb/?p=raisin.git;a=commitdiff;h=5fe3855a6cf69c4aaed89c4
On Sat, Mar 26, 2016 at 12:54:09PM +, Stefano Stabellini wrote:
> are you OK with this patch?
Nothing against it, but the only arm64 bit is:
> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index 450987d..6cf5051 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/a
flight 87820 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87820/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs.
86491
test-amd64-am
Hi Shannon,
On 25/03/16 13:48, Shannon Zhao wrote:
Map the UEFI and ACPI tables which we created to non-RAM space in Dom0.
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
With the suggestion below:
Acked-by: Julien Grall
---
v7: flush the cache
---
xen/arch/arm/domain_buil
>>> On 24.03.16 at 09:29, wrote:
> The offset at which components xsaved by xsave[sc] are not fixed.
> So when when a save with v->fpu_dirtied set is followed by one
> with v->fpu_dirtied clear, non-lazy xsave[sc] may overwriting data
> written by the lazy one.
>
> The solution is when using_xsav
On Tue, 2016-03-29 at 10:46 -0400, Boris Ostrovsky wrote:
> On 03/29/2016 10:19 AM, Toshi Kani wrote:
> > On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote:
> >
> > > > I'd appreciate if someone can test this patch-set on Xen to verify
> > > > that there is no change in "x86/PAT: Configuration
flight 87883 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87883/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 87376
Tests which di
Hi Shannon,
On 25/03/16 13:48, Shannon Zhao wrote:
Prepare EFI system table for Dom0 to describe the information of UEFI.
Signed-off-by: Parth Dixit
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
Acked-by: Julien Grall
Regards,
--
Julien Grall
_
Hi Shannon,
On 25/03/16 13:48, Shannon Zhao wrote:
Create EFI memory descriptors to tell Dom0 the RAM region information,
ACPI table regions and EFI tables reserved regions.
Signed-off-by: Parth Dixit
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
Acked-by: Julien Grall
Regar
On 03/29/2016 10:19 AM, Toshi Kani wrote:
On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote:
I'd appreciate if someone can test this patch-set on Xen to verify that
there is no change in "x86/PAT: Configuration [0-7] .." message in
dmesg.
So I don't have a Xen setup, but hopefully such test
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 24.03.16 at 09:29, wrote:
> static void *get_xsave_addr(struct xsave_struct *xsave,
> -unsigned int xfeature_idx)
> +const uint16_t *comp_offsets,
> +unsigned int xfeature_idx)
> {
> if ( !((1ul << xfeature_idx) & xsave-
> >> +static int usbback_is_loaded(libxl__gc *gc)
> >> +{
> >> +int r;
> >> +struct stat st;
> >> +
> >> +r = lstat(SYSFS_USBBACK_DRIVER, &st);
> >> +
> >> +if (r == 0)
> >> +return 1;
> >> +if (r < 0 && errno == ENOENT)
> >> +return 0;
> >
> > I believe the COD
On March 29, 2016 10:21pm, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 29, 2016 at 01:32:02AM +, Xu, Quan wrote:
> > On March 28, 2016 10:11pm, Konrad Rzeszutek Wilk
> wrote:
> > > >
> > > > > > +list_del(&pdev->domain_list);
> > > > > > +pdev->domain = NULL;
> > > > >
On 29/03/16 16:27, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 29, 2016 at 06:44:32AM +0200, Juergen Gross wrote:
>> On 28/03/16 16:50, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Mar 22, 2016 at 08:29:23AM +0100, Juergen Gross wrote:
Today the device model (qemu) is started for a pv domain only i
On 29/03/16 16:24, Konrad Rzeszutek Wilk wrote:
+static int usbback_is_loaded(libxl__gc *gc)
+{
+int r;
+struct stat st;
+
+r = lstat(SYSFS_USBBACK_DRIVER, &st);
+
+if (r == 0)
+return 1;
+if (r < 0 && errno == ENOENT)
>>
On Tue, Mar 29, 2016 at 06:44:32AM +0200, Juergen Gross wrote:
> On 28/03/16 16:50, Konrad Rzeszutek Wilk wrote:
> > On Tue, Mar 22, 2016 at 08:29:23AM +0100, Juergen Gross wrote:
> >> Today the device model (qemu) is started for a pv domain only in case
> >> a device requiring qemu is specified in
On Tue, Mar 29, 2016 at 01:32:02AM +, Xu, Quan wrote:
> On March 28, 2016 10:11pm, Konrad Rzeszutek Wilk
> wrote:
> > >
> > > > > +list_del(&pdev->domain_list);
> > > > > +pdev->domain = NULL;
> > > > > +pci_hide_existing_device(pdev);
> > > > > +
On 03/29/2016 04:56 AM, Steven Haigh wrote:
Interestingly enough, this just happened again - but on a different
virtual machine. I'm starting to wonder if this may have something to do
with the uptime of the machine - as the system that this seems to happen
to is always different.
Destroying it
On 29/03/16 15:00, Juergen Gross wrote:
> On 29/03/16 15:54, George Dunlap wrote:
>> On 25/03/16 08:54, Juergen Gross wrote:
>>> On 24/03/16 12:38, George Dunlap wrote:
On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
wrote:
> On 24/03/16 10:58, Juergen Gross wrote:
>> I've search
On 29/03/16 15:54, George Dunlap wrote:
> On 25/03/16 08:54, Juergen Gross wrote:
>> On 24/03/16 12:38, George Dunlap wrote:
>>> On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
>>> wrote:
On 24/03/16 10:58, Juergen Gross wrote:
> I've searched a little bit in git history in order to under
On 25/03/16 08:54, Juergen Gross wrote:
> On 24/03/16 12:38, George Dunlap wrote:
>> On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
>> wrote:
>>> On 24/03/16 10:58, Juergen Gross wrote:
I've searched a little bit in git history in order to understand why
xen-detect has been invented and
And accomodate platform time source initialization in
try_platform_time(). This is a preparatory patch for deferring
TSC clocksource initialization to the stage where all CPUS are
up (verify_tsc_reliability init call).
Signed-off-by: Joao Martins
---
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew C
Hey,
This series is the v2 of pvclock TSC series (v1 presented here [0]).
PVCLOCK_TSC_STABLE_BIT is the flag telling the guest that the
vcpu_time_info (pvti) are monotonic as seen by any CPU, a feature
which is currently not supported. As it is (i.e. bindly setting the
flag), we can observe that
Introduce support for using TSC as platform time which is the highest
resolution time and most performant to get (~20 nsecs). Though there
are also several problems associated with its usage, and there isn't a
complete (and architecturally defined) guarantee that all machines
will provide reliable
When using TSC as clocksource we will solely rely on TSC for updating
vcpu time infos (pvti). Right now, each vCPU takes the tsc_timestamp
at different instants meaning every EPOCH + delta. This delta is
variable depending on the time the CPU calibrates with CPU 0 (master),
and will likely be diff
To fetch the last read from the clocksource which was used to
calculate system_time. In the case of clocksource=tsc we will
use it to set tsc_timestamp.
Signed-off-by: Joao Martins
Reviewed-by: Andrew Cooper
---
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
Changes since v1:
- Add missi
And use to initialize platform time solely for clocksource=tsc,
as opposed to initializing platform overflow timer, which would
only fire in ~180 years (on 2.2 Ghz Broadwell processor).
Signed-off-by: Joao Martins
Reviewed-by: Andrew Cooper
---
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
This field has two possible flags (as of latest pvclock ABI
shared with KVM).
flags: bits in this field indicate extended capabilities
coordinated between the guest and the hypervisor. Specifically
on KVM, availability of specific flags has to be checked in
0x4001 cpuid leaf. On Xen, we don't
>>> On 04.03.16 at 09:21, wrote:
> In the course of backporting other XSA fixes to very old trees I had
> noticed that the XSA-155 had shrunk to just the change to
> xen/include/public/io/ring.h at some point, which didn't seem right.
> Clearly up to 4.5 the situation of blktap1 is the same as tha
On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote:
> * Toshi Kani wrote:
>
> > A Xorg failure on qemu32 was reported as a regression [1] caused by
> > 'commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")'.
> > This patch-set fixes the regression.
> >
> > Negative effects of th
1 - 100 of 157 matches
Mail list logo
