This run is configured for baseline tests only.
flight 68473 qemu-upstream-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68473/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-armhf-armhf-libvirt 13 save
flight 104788 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104788/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken REGR. vs. 104662
test-amd64-i386-q
This run is configured for baseline tests only.
flight 68470 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68470/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 1 build-check(1)
flight 104771 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104771/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs.
104681
test-amd64-i3
This run is configured for baseline tests only.
flight 68472 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68472/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 1 build
This run is configured for baseline tests only.
flight 68471 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68471/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 1 build-check(1)
flight 104767 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104767/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 59254
test-armhf-armhf-li
This run is configured for baseline tests only.
flight 68469 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68469/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-xtf-amd64-amd64-2 20 xtf/test-hvm32-in
Commit 7478ebe1602e6 ("xen: credit2: fix shutdown/suspend
when playing with cpupools"), while doing the right thing
for actual code, forgot to update the ASSERT()s accordingly,
in csched2_vcpu_migrate().
In fact, as stated there already, during shutdown/suspend,
we must allow a Credit2 vCPU to tem
This run is configured for baseline tests only.
flight 68468 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68468/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-xtf-amd64-amd64-2 20 xtf/test-hvm32-in
On Fri, 27 Jan 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 27/01/2017 20:41, Stefano Stabellini wrote:
> > On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
> > > When the toolstack modifies memory of a running ARM VM it may happen
> > > that the underlying memory of a current vCPU PC is changed. Wit
On Thu, 26 Jan 2017, Paul Durrant wrote:
> ...not just IDE and SCSI.
>
> This patch allows the Xen tool-stack to fully support of NVMe as an
> emulated disk type. See [1] for the relevant tool-stack patch discussion.
>
> [1] https://lists.xen.org/archives/html/xen-devel/2017-01/msg01225.html
>
>
flight 104761 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104761/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 1046
On Wed, 25 Jan 2017, Anthony PERARD wrote:
> On Mon, Nov 28, 2016 at 10:14:00AM -0800, Stefano Stabellini wrote:
> > On Fri, 25 Nov 2016, Anthony PERARD wrote:
> > > Signed-off-by: Anthony PERARD
> >
> > Acked-by: Stefano Stabellini
>
> Hi,
>
> This patch has never been applied.
Sorry, it's o
On Wed, 25 Jan 2017, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 05, 2017 at 04:54:37PM -0800, Stefano Stabellini wrote:
> > Changes in v3:
> > - clarify a few statements
> > - rename port- to event-channel-
> > - use grant_ref_t ref[1] instead of ref[]
> >
> > Changes in v2:
> > - fix copy/paste e
flight 104752 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail REGR. vs. 104616
test-amd64-amd64-xl
On Mon, Oct 10, 2016 at 08:32:35AM +0800, Haozhong Zhang wrote:
> QMP command 'query-nvdimms' is used by libxl to get the backend, the
> guest SPA and size of each vNVDIMM device, and then libxl starts mapping
> backend to guest for each vNVDIMM device.
>
> Signed-off-by: Haozhong Zhang
> ---
> C
On Mon, Oct 10, 2016 at 08:32:34AM +0800, Haozhong Zhang wrote:
> If any error code is returned when creating a domain, stop the domain
> creation.
This looks like it is a bug-fix that can be spun off from this
patchset?
>
> Signed-off-by: Haozhong Zhang
> ---
> Cc: Ian Jackson
> Cc: Wei Liu
On Mon, Oct 10, 2016 at 08:32:33AM +0800, Haozhong Zhang wrote:
> We can map host pmem devices or files on pmem devices to guests. This
> patch adds support to map files on pmem devices. The implementation
> relies on the Linux pmem driver and kernel APIs, so it currently
May want to mention which
..snip..
> > +mfn = host_spa >> XC_PAGE_SHIFT;
> > +gpfn = guest_spa >> XC_PAGE_SHIFT;
> > +nr_gpfns = guest_size >> XC_PAGE_SHIFT;
> > +
> > +switch ( st.st_mode & S_IFMT )
> > +{
> > +case S_IFBLK:
> > +ret = add_pages(gc, domid, mfn, gpfn, nr_gpfns);
>
> You will
On Mon, Oct 10, 2016 at 08:32:32AM +0800, Haozhong Zhang wrote:
> We can map host pmem devices or files on pmem devices to guests. This
> patch adds support to map pmem devices. The implementation relies on the
> Linux pmem driver, so it currently functions only when libxl is compiled
Perhaps say
On Mon, Oct 10, 2016 at 08:32:31AM +0800, Haozhong Zhang wrote:
> For xl vNVDIMM configs
> vnvdimms = [ '/path/to/pmem0', '/path/to/pmem1', ... ]
>
> the following qemu options are built
> -machine ,nvdimm
> -m ,slots=$NR_SLOTS,maxmem=$MEM_SIZE
> -object memory-backend-xen,id=mem1,size=$PM
On Mon, Oct 10, 2016 at 08:32:31AM +0800, Haozhong Zhang wrote:
> For xl vNVDIMM configs
> vnvdimms = [ '/path/to/pmem0', '/path/to/pmem1', ... ]
>
> the following qemu options are built
> -machine ,nvdimm
> -m ,slots=$NR_SLOTS,maxmem=$MEM_SIZE
> -object memory-backend-xen,id=mem1,size=$PM
On Mon, Oct 10, 2016 at 08:32:30AM +0800, Haozhong Zhang wrote:
> ACPI tables built by the device model, whose signatures do not
> conflict with tables built by Xen (except SSDT), are loaded after ACPI
> tables built by Xen.
>
> ACPI namespace devices built by the device model, whose names do not
Hi,
On 27/01/2017 20:54, Tamas K Lengyel wrote:
On Fri, Jan 27, 2017 at 1:41 PM, Stefano Stabellini
wrote:
On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flush
On Mon, Oct 10, 2016 at 08:32:29AM +0800, Haozhong Zhang wrote:
> It is used by libacpi to generate SSDTs from ACPI namespace devices
> built by the device model.
Would it make sense to include a link to document outlining the
the AML code? Or perhaps even just include an simple example
of ASL and
On Mon, Oct 10, 2016 at 08:32:28AM +0800, Haozhong Zhang wrote:
> libacpi needs to access information placed in XenStore in order to load
> ACPI built by the device model.
>
> Signed-off-by: Haozhong Zhang
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Ian Jackson
> Cc: Wei Liu
> ---
> to
Hi Stefano,
On 27/01/2017 20:41, Stefano Stabellini wrote:
On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing sta
On Mon, Oct 10, 2016 at 08:32:27AM +0800, Haozhong Zhang wrote:
> Expose the minimal allocation unit and the minimal alignment used by the
> memory allocator, so that certain ACPI code (e.g. the AML builder added
> later) can get contiguous memory allocated by multiple calls to
s/later/in patch ti
On Fri, Jan 27, 2017 at 1:41 PM, Stefano Stabellini
wrote:
> On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
>> When the toolstack modifies memory of a running ARM VM it may happen
>> that the underlying memory of a current vCPU PC is changed. Without
>> flushing the icache the vCPU may continue execu
On Mon, Oct 10, 2016 at 08:32:26AM +0800, Haozhong Zhang wrote:
> This callback is used when libacpi needs to in-place access ACPI built
> by the device model, whose address is specified in the physical address.
May I recommend you write:
This callback is used when libacpi needs to access ACPI bl
On Mon, Oct 10, 2016 at 08:32:25AM +0800, Haozhong Zhang wrote:
> One guest page is reserved for the device model to place guest ACPI. The
guest ACPI what? ACPI SSDT? MADT?
Also why one page? What if there is a need for more than one page?
You add HVM_XS_DM_ACPI_LENGTH which makes me think this
Hi Stefano,
On 27/01/2017 19:27, Stefano Stabellini wrote:
On Thu, 26 Jan 2017, Tamas K Lengyel wrote:
On Thu, Jan 26, 2017 at 10:54 AM, Tamas K Lengyel
wrote:
On Thu, Jan 26, 2017 at 4:30 AM, Julien Grall wrote:
So according to the manual (C5.3.9-10) IALLU and IALLUIS are not
available fro
On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
> When the toolstack modifies memory of a running ARM VM it may happen
> that the underlying memory of a current vCPU PC is changed. Without
> flushing the icache the vCPU may continue executing stale instructions.
>
> Also expose the xc_domain_cacheflus
On Fri, 27 Jan 2017, Konrad Rzeszutek Wilk wrote:
> > >
> > > ## Ring Setup
> > >
> > > The shared page has the following layout:
> > >
> > > typedef uint32_t XEN_9PFS_RING_IDX;
> > >
> > > struct xen_9pfs_intf {
> > > XEN_9PFS_RING_IDX in_cons, in_prod, in_event;
> > >
> >
> > ## Ring Setup
> >
> > The shared page has the following layout:
> >
> > typedef uint32_t XEN_9PFS_RING_IDX;
> >
> > struct xen_9pfs_intf {
> > XEN_9PFS_RING_IDX in_cons, in_prod, in_event;
> > XEN_9PFS_RING_IDX out_cons, out_prod, out_event;
> >
> >
At 09:40 -0700 on 27 Jan (1485510008), Jan Beulich wrote:
> >>> On 27.01.17 at 14:20, wrote:
> > At 12:51 + on 27 Jan (1485521470), Andrew Cooper wrote:
> >> On 27/01/17 11:14, Tim Deegan wrote:
> >> > But looking at it now, I'm not convinced of exactly how. The magic
> >> > bitmap in the TSS
> Despite being owned by the guest, this TSS is actually managed by
Xen.
> It should be initialised to defaults each time Xen needs to use it
on
> behalf of the guest.
At 14:35 + on 27 Jan (1485527708), Andrew Cooper wrote:
> On 27/01/17 14:01, Tim Deegan wrote:
> > Hi,
> >
> > At 13:46 +
On Fri, 27 Jan 2017, Jan Beulich wrote:
> >>> On 27.01.17 at 09:59, wrote:
> > version targeted for testing:
> > xen b29aed8b0355fe9f7d49faa9aef12b2f8f983c2c
> > baseline version:
> > xen e1cefedd80f9972854769bfc6e32e23b56cd0712
> >
> > Last test of basis 104
On 23/01/17 16:43, Ronald Rojas wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings. Also add a stub package which only opens libxl context.
>
> Include a global xenlight.Ctx variable which can be used as the
> default context by the entire program if desired.
>
>
On Thu, Jan 26, 2017 at 11:52 AM, Dario Faggioli
wrote:
> Scheduling information debug dump for Credit2 is hard
> to read as it contains the same information repeated
> multiple time in different ways.
>
> In fact, in Credit2, CPUs are grouped in runqueus.
> Here's the current debug output:
>
> C
On Thu, 26 Jan 2017, Tamas K Lengyel wrote:
> On Thu, Jan 26, 2017 at 10:54 AM, Tamas K Lengyel
> wrote:
> > On Thu, Jan 26, 2017 at 4:30 AM, Julien Grall wrote:
> >> (CC xen-devel, Ravzan, and Stefao)
> >>
> >> Hi Tamas,
> >>
> >> Not sure why you only CC me on the answer. I have CCed again xen-
>
> > > TBH, what I don't especially like in the output above is, within
> > > the
> > > vCPU info being printed:
> > > - the spaces inside '[' ']';
> > > - the big numbers;
> > > - the fact that last_start is rather useless (it's more tracing
> > > info
> > >than debug dump info, IMO);
> >
On Fri, 27 Jan 2017, Bhupinder Thakur wrote:
> Hi,
>
> I have done the changes for emulating pl011 in Xen. Currently, I have
> verified the emulation code by manually reading/writing data to
> /dev/ttyAMA0 which is the device file for pl011 device. The data is
> flowing fine between xenconsoled an
On Fri, Jan 27, 2017 at 11:30 AM, Andrew Cooper
wrote:
> On 27/01/17 18:22, Tamas K Lengyel wrote:
>> On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos wrote:
>>> Hello,
>>>
>>> In developing against the altp2m API, I've encountered something I
>>> wasn't expecting.
>>>
>>> Here's the scenario:
>>>
>
On Fri, Jan 27, 2017 at 08:38:29PM +0200, Oleksandr Andrushchenko wrote:
>
>
> On 01/27/2017 08:13 PM, Konrad Rzeszutek Wilk wrote:
> > .snip..
> > > I am looking at this from FAE's or integrator's POV, when one would need
> > FAE?
> >
> Field Applications Engineer
> > > to touch different parts
On 01/27/2017 11:47 AM, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
>
> Please pull in your 'for-linus' branch two little fixes for Xen
> block front:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> stable/for-jens-4.10
>
> One fix is for handling the XEN_PAGE_SIZE != PAGE_SIZE
Hey Jens,
Please pull in your 'for-linus' branch two little fixes for Xen
block front:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-jens-4.10
One fix is for handling the XEN_PAGE_SIZE != PAGE_SIZE (4KB vs 64KB
on ARM for example) mishandling while the other is fixing
On Fri, 27 Jan 2017, Oleksandr Andrushchenko wrote:
> Hi, Stefano!
> > Error numbers
> >
> > The numbers corresponding to the error names specified by POSIX are:
> >
> > [EPERM] -1
> > [ENOENT]-2
> >
> Don't you want to use Xen's errno.h here as described in [1]?
>
On 01/27/2017 08:13 PM, Konrad Rzeszutek Wilk wrote:
.snip..
I am looking at this from FAE's or integrator's POV, when one would need
FAE?
Field Applications Engineer
to touch different parts of the system. "/0/0/0" makes me feel
sad just because either you have to keep all those numbers i
On Fri, 2017-01-27 at 12:05 -0500, Meng Xu wrote:
> On Thu, Jan 26, 2017 at 5:08 PM, Dario Faggioli
> wrote:
> > "Runqueue 0" tells that what follow is information about the pCPUs
> > and
> > the vCPUs of that runqueue (it's the same label used above for,
> > showing
> > more general runqueue info
On 27/01/17 18:22, Tamas K Lengyel wrote:
> On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos wrote:
>> Hello,
>>
>> In developing against the altp2m API, I've encountered something I
>> wasn't expecting.
>>
>> Here's the scenario:
>>
>> 1. Create a new altp2m memory view. Assume we get view ID 1.
>>
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.
Also expose the xc_domain_cacheflush through xenctrl.h.
Signed-off-by: Tamas K Lengyel
On Fri, Jan 27, 2017 at 11:20 AM, Julien Grall wrote:
> Hi Tamas,
>
> On 27/01/17 18:17, Tamas K Lengyel wrote:
>>
>> When the toolstack modifies memory of a running ARM VM it may happen
>> that the underlying memory of a current vCPU PC is changed. Without
>> flushing the icache the vCPU may cont
On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos wrote:
> Hello,
>
> In developing against the altp2m API, I've encountered something I
> wasn't expecting.
>
> Here's the scenario:
>
> 1. Create a new altp2m memory view. Assume we get view ID 1.
> 2. Change some MFN permissions in view 1.
> 3. Destro
Hi Tamas,
On 27/01/17 18:17, Tamas K Lengyel wrote:
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.
In this patch we introduce VA-base
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.
In this patch we introduce VA-based icache flushing macros. Also expose
the xc_domain_cac
.snip..
> I am looking at this from FAE's or integrator's POV, when one would need
FAE?
> to touch different parts of the system. "/0/0/0" makes me feel
> sad just because either you have to keep all those numbers in mind (like you
> do)
> or have documentation available (and know where it is, e.
(CC Artem as ARM coverity admin)
Hi Stefano,
On 03/01/17 23:29, Stefano Stabellini wrote:
Always set the new physical irq affinity at the beginning of
vgic_migrate_irq, in all cases.
No need to set physical irq affinity in gic_update_one_lr anymore,
solving the lock inversion problem.
After m
On 27/01/17 16:40, Jan Beulich wrote:
On 27.01.17 at 14:20, wrote:
>> At 12:51 + on 27 Jan (1485521470), Andrew Cooper wrote:
>>> On 27/01/17 11:14, Tim Deegan wrote:
But looking at it now, I'm not convinced of exactly how. The magic
bitmap in the TSS is at [I/O Map Base Addres
On Fri, Jan 27, 2017 at 10:25 AM, Julien Grall wrote:
> Hello Tamas,
>
> Please give a bit more time to people for reviewing before sending a new
> version. Patches adding cache instruction are never easy to review.
>
> On 27/01/17 16:45, Tamas K Lengyel wrote:
>>
>> When the toolstack modifies me
On Fri, Jan 27, 2017 at 05:22:03PM +, Roger Pau Monne wrote:
> On Thu, Jan 26, 2017 at 06:37:00AM -0700, Jan Beulich wrote:
> > >>> On 19.01.17 at 18:29, wrote:
> > > @@ -1959,12 +1960,146 @@ static int __init pvh_setup_p2m(struct domain *d)
> > > #undef MB1_PAGES
> > > }
> > >
> > > +stat
flight 104751 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104751/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in
104736
test-amd64-i386-xl-raw
On Fri, Jan 27, 2017 at 05:22:03PM +, Roger Pau Monne wrote:
> On Thu, Jan 26, 2017 at 06:37:00AM -0700, Jan Beulich wrote:
> > >>> On 19.01.17 at 18:29, wrote:
> > > +if ( cmdline != NULL )
> > > +{
> > > +rc = hvm_copy_to_guest_phys_vcpu(last_addr, cmdline,
> > > +
Hello Tamas,
Please give a bit more time to people for reviewing before sending a new
version. Patches adding cache instruction are never easy to review.
On 27/01/17 16:45, Tamas K Lengyel wrote:
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory o
On Thu, Jan 26, 2017 at 06:37:00AM -0700, Jan Beulich wrote:
> >>> On 19.01.17 at 18:29, wrote:
> > @@ -1959,12 +1960,146 @@ static int __init pvh_setup_p2m(struct domain *d)
> > #undef MB1_PAGES
> > }
> >
> > +static int __init pvh_load_kernel(struct domain *d, const module_t *image,
> > +
On 01/27/2017 06:36 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 27, 2017 at 05:50:36PM +0200, Oleksandr Andrushchenko wrote:
thank you for comments, please find answers below
Can we please switch to v16 discussion as v15 vs v16 is
a big change?
This channel seemed appropiate to hash this ou
On Thu, Jan 26, 2017 at 02:36:07PM +0800, Zhang Chen wrote:
> Qemu need this args to start userspace colo-proxy.
>
> Signed-off-by: Zhang Chen
Since we have:
# Note that the COLO configuration settings should be considered unstable.
# They may change incompatibly in future versions of Xen
On Thu, Jan 26, 2017 at 5:08 PM, Dario Faggioli
wrote:
> On Thu, 2017-01-26 at 13:59 -0500, Meng Xu wrote:
>> Hi Dario,
>>
> Hi,
>
>> On Thu, Jan 26, 2017 at 11:52 AM, Dario Faggioli
>> wrote:
>> >
>> > Runqueue 0:
>> > CPU[00] runq=0, sibling=,0003, core=,00ff
>> >
On Thu, Jan 26, 2017 at 02:36:06PM +0800, Zhang Chen wrote:
> In this patch we add a function to close
> kernel COLO-Proxy on secondary side.
>
> Signed-off-by: Zhang Chen
> ---
> tools/libxl/libxl_colo_restore.c | 9 +++--
> tools/libxl/libxl_create.c | 9 +++--
> tools/libxl/li
On Thu, Jan 26, 2017 at 02:36:08PM +0800, Zhang Chen wrote:
> Qemu need this args to start userspace colo-proxy.
>
> Signed-off-by: Zhang Chen
See previous patch. Same comments apply here.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https
On Fri, Jan 27, 2017 at 09:45:45AM -0700, Tamas K Lengyel wrote:
> When the toolstack modifies memory of a running ARM VM it may happen
> that the underlying memory of a current vCPU PC is changed. Without
> flushing the icache the vCPU may continue executing stale instructions.
>
> In this patch
On Thu, Jan 26, 2017 at 02:36:03PM +0800, Zhang Chen wrote:
> Hi~ All~ Happy Chinese New Year~~
Happy Chinese New Year to you, too!
I skimmed through this series and made some comments based on my
preliminary assessment. If you have any questions, feel free to ask.
I suppose we would need to hav
On Thu, Jan 26, 2017 at 02:36:05PM +0800, Zhang Chen wrote:
> In this patch we close kernel COLO-Proxy on primary side.
>
> Signed-off-by: Zhang Chen
Acked-by: Wei Liu
I don't claim I know much about COLO though, nor have I ever run it, so
it would be better to have a second eye on this patch.
On Thu, Jan 26, 2017 at 02:36:09PM +0800, Zhang Chen wrote:
> We use old kernel colo proxy way to get the checkpoint event from qemu.
> This patch have some TODO job.
> Qemu compare need add a API to support this(I will add this in qemu).
>
> Signed-off-by: Zhang Chen
No major objection but this
On Thu, Jan 26, 2017 at 02:36:04PM +0800, Zhang Chen wrote:
> Add remus '-p' to enable userspace colo proxy(in qemu).
>
> Signed-off-by: Zhang Chen
> ---
> docs/man/xl.pod.1.in | 4
> tools/libxl/libxl_colo.h | 5 +
> tools/libxl/libxl_colo_save.c | 2 ++
> tools/libxl/
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.
In this patch we introduce VA-based icache flushing macros. Also expose
the xc_domain_cac
>>> On 27.01.17 at 14:20, wrote:
> At 12:51 + on 27 Jan (1485521470), Andrew Cooper wrote:
>> On 27/01/17 11:14, Tim Deegan wrote:
>> > But looking at it now, I'm not convinced of exactly how. The magic
>> > bitmap in the TSS is at [I/O Map Base Address] - 32, and the I/O map
>> > base addres
On Fri, Jan 27, 2017 at 05:50:36PM +0200, Oleksandr Andrushchenko wrote:
> thank you for comments, please find answers below
>
> Can we please switch to v16 discussion as v15 vs v16 is
> a big change?
This channel seemed appropiate to hash this out. I will
look at v16 next week (out of time for
On Fri, Jan 27, 2017 at 09:32:25AM -0700, Tamas K Lengyel wrote:
> On Fri, Jan 27, 2017 at 9:29 AM, Julien Grall wrote:
> > Hi Tamas,
> >
> > On 27/01/17 16:23, Tamas K Lengyel wrote:
> >>
> >> On Fri, Jan 27, 2017 at 9:15 AM, Julien Grall
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> On 27/01/17 15
On Fri, Jan 27, 2017 at 9:29 AM, Julien Grall wrote:
> Hi Tamas,
>
> On 27/01/17 16:23, Tamas K Lengyel wrote:
>>
>> On Fri, Jan 27, 2017 at 9:15 AM, Julien Grall
>> wrote:
>>>
>>> Hello,
>>>
>>> On 27/01/17 15:52, Tamas K Lengyel wrote:
Well, yes, only ARM could _should_ call this
>>> On 27.01.17 at 17:04, wrote:
> On Fri, Jan 27, 2017 at 08:11:56AM -0700, Jan Beulich wrote:
>> >>> On 27.01.17 at 13:23, wrote:
>> > On Thu, Jan 26, 2017 at 05:41:58AM -0700, Jan Beulich wrote:
>> >> >>> On 19.01.17 at 18:29, wrote:
>> >> > @@ -43,6 +44,9 @@ static long __initdata dom0_nrpag
Hi Tamas,
On 27/01/17 16:23, Tamas K Lengyel wrote:
On Fri, Jan 27, 2017 at 9:15 AM, Julien Grall wrote:
Hello,
On 27/01/17 15:52, Tamas K Lengyel wrote:
Well, yes, only ARM could _should_ call this function. The comment I
think is important to tell the user don't expect it to do anything o
On Fri, Jan 27, 2017 at 9:15 AM, Julien Grall wrote:
> Hello,
>
> On 27/01/17 15:52, Tamas K Lengyel wrote:
>>
>> Well, yes, only ARM could _should_ call this function. The comment I
>> think is important to tell the user don't expect it to do anything on
>> x86. Doesn't mean they can't call it t
Hello,
On 27/01/17 15:52, Tamas K Lengyel wrote:
Well, yes, only ARM could _should_ call this function. The comment I
think is important to tell the user don't expect it to do anything on
x86. Doesn't mean they can't call it though - if that was the case it
would be wrapped in an ifdef like all
On January 27, 2017 12:31:19 AM PST, Juergen Gross wrote:
>On 27/01/17 09:26, Oleksandr Andrushchenko wrote:
>> On 01/27/2017 10:14 AM, Juergen Gross wrote:
>>> On 27/01/17 08:53, Oleksandr Andrushchenko wrote:
On 01/27/2017 09:46 AM, Juergen Gross wrote:
> On 27/01/17 08:21, Oleksandr An
On Fri, Jan 27, 2017 at 08:52:50AM -0700, Tamas K Lengyel wrote:
> On Jan 27, 2017 08:43, "Wei Liu" wrote:
>
> On Fri, Jan 27, 2017 at 08:37:33AM -0700, Tamas K Lengyel wrote:
> > On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu wrote:
> > > On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrot
On Fri, Jan 27, 2017 at 08:11:56AM -0700, Jan Beulich wrote:
> >>> On 27.01.17 at 13:23, wrote:
> > On Thu, Jan 26, 2017 at 05:41:58AM -0700, Jan Beulich wrote:
> >> >>> On 19.01.17 at 18:29, wrote:
> >> > @@ -43,6 +44,9 @@ static long __initdata dom0_nrpages;
> >> > static long __initdata dom0_
On Jan 27, 2017 08:43, "Wei Liu" wrote:
On Fri, Jan 27, 2017 at 08:37:33AM -0700, Tamas K Lengyel wrote:
> On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu wrote:
> > On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrote:
> >> When the toolstack modifies memory of a running ARM VM it may happe
thank you for comments, please find answers below
Can we please switch to v16 discussion as v15 vs v16 is
a big change?
On 01/27/2017 05:14 PM, Konrad Rzeszutek Wilk wrote:
On Thu, Jan 26, 2017 at 12:02:49PM +0200, Oleksandr Andrushchenko wrote:
Hi, Konrad!
First of all thank you very much fo
Hello,
In developing against the altp2m API, I've encountered something I
wasn't expecting.
Here's the scenario:
1. Create a new altp2m memory view. Assume we get view ID 1.
2. Change some MFN permissions in view 1.
3. Destroy view 1.
4. Create another altp2m view. Get view ID 1 again.
Now, I
On Fri, Jan 27, 2017 at 08:37:33AM -0700, Tamas K Lengyel wrote:
> On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu wrote:
> > On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrote:
> >> When the toolstack modifies memory of a running ARM VM it may happen
> >> that the underlying memory of a cur
On 26/01/17 20:41, Boris Ostrovsky wrote:
> Like PV guests, PVH does not have PCI devices and therefore cannot
> use MMIO space to store grants. Instead it balloons out memory and
> keeps grants there.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Juergen
___
On 26/01/17 20:41, Boris Ostrovsky wrote:
> Using native_machine_emergency_restart (called during reboot) will
> lead PVH guests to machine_real_restart() where we try to use
> real_mode_header which is not initialized.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Juergen
On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu wrote:
> On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrote:
>> When the toolstack modifies memory of a running ARM VM it may happen
>> that the underlying memory of a current vCPU PC is changed. Without
>> flushing the icache the vCPU may cont
. snip ..
> > Signed-off-by: David Woodhouse
>
> Reviewed-by: Jan Beulich
>
> But before committing I'd prefer to have a VMX maintainer ack
> too.
Who is gone until Feb yth (Spring festival in China).
___
Xen-devel mailing list
Xen-devel@lists.xen.o
On 26/01/17 20:41, Boris Ostrovsky wrote:
> PVH guests don't (yet) receive ACPI hotplug interrupts and therefore
> need to monitor xenstore for CPU hotplug event.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel m
flight 104743 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 104681
test-am
On Thu, Jan 19, 2017 at 02:01:23PM +0800, Yi Sun wrote:
> This patch implements xl/xc changes to support get HW info
> for L2 CAT.
>
> 'xl psr-hwinfo' is updated to show both L3 CAT and L2 CAT
> info.
>
> Example(on machine which only supports L2 CAT):
> Cache Monitoring Technology (CMT):
> Enabl
On Thu, Jan 19, 2017 at 02:01:26PM +0800, Yi Sun wrote:
> This patch adds L2 CAT description in related documents.
>
> Signed-off-by: He Chen
> Signed-off-by: Yi Sun
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.
1 - 100 of 154 matches
Mail list logo
