On 08/02/16 08:46, Jan Beulich wrote:
> >>> On 18.07.16 at 02:29, wrote:
> > 4.2.2 Detection of Host pmem Devices
> >
> > The detection and initialize host pmem devices require a non-trivial
> > driver to interact with the corresponding ACPI namespace devices,
> > parse namespace labels and ma
This run is configured for baseline tests only.
flight 66893 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66893/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64 3 host-install(3) bro
flight 99914 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99914/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4884e81b5d0da1bcc05361dd4c5fc06b3722f144
baseline version:
ovmf 846ea5f537c8f8313abb2f8
This run is configured for baseline tests only.
flight 66889 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66889/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3
flight 99912 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99912/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 846ea5f537c8f8313abb2f8f29794d13ac4becec
baseline version:
ovmf a6d594c5fabd8da2273d279
On 02/08/16 20:27, Stefano Stabellini wrote:
> On Tue, 2 Aug 2016, Juergen Gross wrote:
>> Instead of calling xen_be_register() for each supported backend type
>> for hvm and pv guests in their machine init functions use a common
>> function in order not to have to add new backends twice.
>>
>> Thi
This run is configured for baseline tests only.
flight 66892 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66892/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 ho
> On 25/07/16 07:09, Kang, Luwei wrote:
> First of all - please don't top post.
>
> > What about remove the dependency between AVX2 and AVX512F
> >> ( AVX2:
> [AVX512F], ) ?
>
> Yes, that's what I think we want, but we need Andrew's agreement here.
>
> >>> Hi Andre
When specifying a serial list in domain config, users of
libxl_console_get_tty cannot get the tty path of a second specified pty serial,
since right now it always returns the tty path of serial 0.
Signed-off-by: Bob Liu
---
tools/libxl/libxl.c |2 +-
1 file changed, 1 insertion(+), 1 deletio
flight 99910 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99910/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a6d594c5fabd8da2273d2794826ec086cf9c3c04
baseline version:
ovmf 8265373e60ad79acd4a20af
This run is configured for baseline tests only.
flight 66887 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66887/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3)
This run is configured for baseline tests only.
flight 66890 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66890/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build
Hi all,
This is the design document of the PV Calls protocol. You can find
prototypes of the Linux frontend and backend drivers here:
git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-4
To use them, make sure to enable CONFIG_PVCALLS in your kernel config
and add "pvcalls
flight 99906 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99906/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-buildfail like 99897
build-i386-rumpuserxen
flight 99908 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99908/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8265373e60ad79acd4a20affe2c49470c68d6a9c
baseline version:
ovmf 8134f7d9d2654a49916f627
On Tue, Aug 2, 2016 at 4:05 PM, Julien Grall wrote:
>
>
> On 02/08/2016 22:34, Tamas K Lengyel wrote:
>>
>> On Tue, Aug 2, 2016 at 2:02 PM, Julien Grall wrote:
>>>
>>> Hello Tamas,
>>>
>>> Thank you for taking care of this bug.
>>>
>>> On 02/08/2016 19:53, Tamas K Lengyel wrote:
Wh
On 02/08/2016 22:34, Tamas K Lengyel wrote:
On Tue, Aug 2, 2016 at 2:02 PM, Julien Grall wrote:
Hello Tamas,
Thank you for taking care of this bug.
On 02/08/2016 19:53, Tamas K Lengyel wrote:
When mem_access settings change, the active vCPUs may still cause a
violation
until the TLB gets
On Tue, Aug 2, 2016 at 2:02 PM, Julien Grall wrote:
> Hello Tamas,
>
> Thank you for taking care of this bug.
>
> On 02/08/2016 19:53, Tamas K Lengyel wrote:
>>
>> When mem_access settings change, the active vCPUs may still cause a
>> violation
>> until the TLB gets flushed. Instead of just reinje
flight 99909 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99909/
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
This run is configured for baseline tests only.
flight 66886 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66886/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 3 host-install(3)
flight 99904 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99904/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99892
test-amd64-i386-xl-qemuu-win
This run is configured for baseline tests only.
flight 66888 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66888/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 3 ho
Hello Tamas,
Thank you for taking care of this bug.
On 02/08/2016 19:53, Tamas K Lengyel wrote:
When mem_access settings change, the active vCPUs may still cause a violation
until the TLB gets flushed. Instead of just reinjecting the violation to the
guest, in this patch we direct the vCPU to r
> On 2 Aug 2016, at 12:07, Wei Liu wrote:
>
> On Tue, Aug 02, 2016 at 12:39:25PM +0200, Juergen Gross wrote:
>> On a system with systemd the xenstore sockets are created via systemd.
>> Remove the related configuration files in order to be able to decide
>> at runtime whether the sockets should
On 15/06/16 11:26, Jan Beulich wrote:
> Using the bare return value from read_platform_stime() is not suitable
> when local_time_calibration() is going to use its fast path: Divergence
> of several dozen microseconds between NOW() return values on different
> CPUs results when platform and local ti
On 20/06/16 16:19, Jan Beulich wrote:
On 20.06.16 at 16:20, wrote:
>> On 15/06/16 11:28, Jan Beulich wrote:
>>> --- a/xen/arch/x86/i8259.c
>>> +++ b/xen/arch/x86/i8259.c
>>> @@ -359,12 +359,7 @@ void __init init_IRQ(void)
>>>
>>> apic_intr_init();
>>>
>>> -/* Set the clock to HZ
On 04/07/16 16:53, Jan Beulich wrote:
On 04.07.16 at 17:39, wrote:
>> On 20/06/16 16:20, Jan Beulich wrote:
>> On 20.06.16 at 16:32, wrote:
On 15/06/16 11:28, Jan Beulich wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1358,6 +1358,24 @@ static void
> > Can you try
> >
> > ((void *)(md) + (m)->desc_size - 1) <
> > (m)->map_end; \
> >
> > instead?
with the 'baseline' as referenced + a patched kernel
> Can you try
>((void *)(md) + (m)->desc_size - 1) < (m)->map_end;
On Tue, 2 Aug 2016, Olaf Hering wrote:
> As a followup to the issue below, and the one which "just" popped in in
> qemu-2.6+:
>
> Why is the machine description for xen not fixed?
xenfv comes from a time when QEMU didn't have machine description
versioning. To have versioning, it is possible to u
When mem_access settings change, the active vCPUs may still cause a violation
until the TLB gets flushed. Instead of just reinjecting the violation to the
guest, in this patch we direct the vCPU to retry the access where
appropriate or we crash the domain where the mem_access settings are
corrupted
On Tue, 2 Aug 2016, Jan Beulich wrote:
> >>> On 02.08.16 at 16:59, wrote:
> > On 02/08/16 15:54, Jan Beulich wrote:
> > On 02.08.16 at 16:26, wrote:
> >>> On 02/08/16 15:17, Jan Beulich wrote:
> Well, I find it quite odd for hypercall argument counts to differ
> between arches. I.e.
On Thu, Jul 28, 2016 at 03:08:29PM +0100, Andrew Cooper wrote:
> On 28/07/16 11:50, Anthony PERARD wrote:
> > As perform_tests() is going to clear memory past 4MB, we check that the
> > memory can be use or we skip the tests.
> >
> > Signed-off-by: Anthony PERARD
>
> This is a loosing battle of o
On Tue, 2 Aug 2016, Gerd Hoffmann wrote:
> On Di, 2016-08-02 at 08:32 +0200, Juergen Gross wrote:
> > Instead of calling xen_be_register() for each supported backend type
> > for hvm and pv guests in their machine init functions use a common
> > function in order not to have to add new backends twi
On Tue, 2 Aug 2016, Juergen Gross wrote:
> Instead of calling xen_be_register() for each supported backend type
> for hvm and pv guests in their machine init functions use a common
> function in order not to have to add new backends twice.
>
> This at once fixes the error that hvm domains couldn't
On Thu, Jul 28, 2016 at 02:44:24PM +0100, Andrew Cooper wrote:
> On 28/07/16 11:50, Anthony PERARD wrote:
> > @@ -293,8 +340,17 @@ int main(void)
> > }
> >
> > printf("Loading %s ...\n", bios->name);
> > -if ( bios->bios_load )
> > -bios->bios_load(bios);
> > +bios_modul
flight 99907 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99907/
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, Aug 02, 2016 at 08:32:32AM +0200, Juergen Gross wrote:
> Instead of calling xen_be_register() for each supported backend type
> for hvm and pv guests in their machine init functions use a common
> function in order not to have to add new backends twice.
>
> This at once fixes the error tha
Wei Liu:
> On Tue, Aug 02, 2016 at 02:41:58PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("[PATCH] systemd: remove hard-coded pid file in
>> xendriverdomain service"):
>>> Per the discussion in [0], the hard-coded pid file can be removed
>>> completely. Systemd has no trouble figuring out the pid
flight 99903 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99903/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8134f7d9d2654a49916f627783c956f3eca78421
baseline version:
ovmf 28ade7b802e0732cf983901
flight 99902 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99902/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 99894 pass in 99902
test-amd64-amd64-xl-qemuu-debia
On 02/08/16 18:25, Juergen Gross wrote:
> Commit 57f8b13c724023c78fa15a80452d1de3e51a1418 ("libxl: memory size
> in kb requires 64 bit variable") introduced a bug: abs() shouldn't
> be called with an int64_t argument. llabs() is to be used here.
Possibly worth identifying that this was caught by a
Commit 57f8b13c724023c78fa15a80452d1de3e51a1418 ("libxl: memory size
in kb requires 64 bit variable") introduced a bug: abs() shouldn't
be called with an int64_t argument. llabs() is to be used here.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl.c | 2 +-
1 file changed, 1 insertion(+), 1 d
On Tue, Aug 2, 2016 at 10:40 AM, Julien Grall wrote:
>
>
> On 02/08/16 17:05, George Dunlap wrote:
>>
>> On 02/08/16 16:48, Tamas K Lengyel wrote:
>>>
>>> On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap
>>> wrote:
On 02/08/16 08:38, Julien Grall wrote:
>
> Hello Tamas,
>
>
On Tue, Aug 2, 2016 at 10:40 AM, Julien Grall wrote:
>
>
> On 02/08/16 17:05, George Dunlap wrote:
>>
>> On 02/08/16 16:48, Tamas K Lengyel wrote:
>>>
>>> On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap
>>> wrote:
On 02/08/16 08:38, Julien Grall wrote:
>
> Hello Tamas,
>
>
(Removing Paul, adding Lars)
Ravi,
I just got to this thread, and I was quite disappointed with both the
code and the interaction here.
In patch 1, the naming of the min/max is obviously inappropriate, and
a.cmd is compared to HVMOP_cmd_max twice in a row.
In patch 3, unused elements of the str
On 02/08/16 17:05, George Dunlap wrote:
On 02/08/16 16:48, Tamas K Lengyel wrote:
On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap wrote:
On 02/08/16 08:38, Julien Grall wrote:
Hello Tamas,
On 01/08/2016 21:41, Tamas K Lengyel wrote:
On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall
wrote:
we d
On Thu, Jun 23, 2016 at 7:23 PM, Lai, Paul C wrote:
> I'm opposed to moving HVMOP_cmd_min and HVMOP_cmd_max somewhere else. That
> would make reading/understanding of the macros more difficult. This practice
> is common. Also, If min & max are defined elsewhere, it will be more likely
> to l
On Tue, Aug 2, 2016 at 10:13 AM, Jan Beulich wrote:
On 02.08.16 at 18:06, wrote:
>> On Tue, Aug 2, 2016 at 9:23 AM, Tamas K Lengyel
>> wrote:
>>> On Aug 2, 2016 06:45, "Jan Beulich" wrote:
>>> On 01.08.16 at 18:52, wrote:
> +int hvm_monitor_mem_access(struct vcpu* v, bool_t syn
On Tue, Aug 2, 2016 at 10:08 AM, Andrew Cooper
wrote:
> On 02/08/16 08:34, Julien Grall wrote:
>> Hi Andrew,
>>
>> On 02/08/2016 00:14, Andrew Cooper wrote:
>>> On 01/08/2016 19:15, Julien Grall wrote:
On 01/08/16 18:10, Sergej Proskurin wrote:
>
> Hello all,
Hello Sergej,
>
>>> On 02.08.16 at 18:06, wrote:
> On Tue, Aug 2, 2016 at 9:23 AM, Tamas K Lengyel
> wrote:
>> On Aug 2, 2016 06:45, "Jan Beulich" wrote:
>>> >>> On 01.08.16 at 18:52, wrote:
>>> > +int hvm_monitor_mem_access(struct vcpu* v, bool_t sync,
>>> > + vm_event_request_t *re
>>> On 02.08.16 at 17:04, wrote:
> On Tue, Aug 2, 2016, at 07:50 AM, Jan Beulich wrote:
>> - one with some suitable variant of reboot=
>
> What exactly is "some suitable variant of reboot" ?
I can't really tell you which of the possible "reboot=" option values
would work on your system. "reboot=
>>> On 02.08.16 at 17:49, wrote:
> On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote:
>> On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
>> > As this is for the construction of dom0, it would be better to take a
>> > preemptible pointer, loop in construct_dom0(), with
On Tue, Aug 2, 2016 at 10:11 AM, Julien Grall wrote:
>
>
> On 02/08/16 17:00, Tamas K Lengyel wrote:
>>
>> On Tue, Aug 2, 2016 at 1:38 AM, Julien Grall wrote:
>> Hi Julien,
>> as I said our use-case is purely external so I don't have an actual
>> use-case for anything being accessible from within
On 02/08/16 08:34, Julien Grall wrote:
> Hi Andrew,
>
> On 02/08/2016 00:14, Andrew Cooper wrote:
>> On 01/08/2016 19:15, Julien Grall wrote:
>>> On 01/08/16 18:10, Sergej Proskurin wrote:
Hello all,
>>>
>>> Hello Sergej,
>>>
The following patch series can be found on Github[0] and i
On 02/08/16 17:00, Tamas K Lengyel wrote:
On Tue, Aug 2, 2016 at 1:38 AM, Julien Grall wrote:
Hi Julien,
as I said our use-case is purely external so I don't have an actual
use-case for anything being accessible from within the guest. However,
I could imagine the gfn remapping be used to prote
Instead of trying to read xenstore via xenstore-read use the pidfile
of xenstored for the test whether xenstored is running. This prepares
support of xenstore domain, as trying to read xenstore will block
for ever in case xenstore domain is started after trying to read.
Signed-off-by: Juergen Gros
On Mon, Aug 01, 2016 at 03:19:35PM +0100, Wei Liu wrote:
> On Mon, Aug 01, 2016 at 09:57:10AM +0100, Paul Durrant wrote:
> > The xenstore-paths documentation specifies various control/feature-XXX
> > flags to allow a guest to tell a toolstack about its abilities to
> > respond to values written to
On Tue, Aug 2, 2016 at 10:05 AM, George Dunlap wrote:
> On 02/08/16 16:48, Tamas K Lengyel wrote:
>> On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap
>> wrote:
>>> On 02/08/16 08:38, Julien Grall wrote:
Hello Tamas,
On 01/08/2016 21:41, Tamas K Lengyel wrote:
> On Mon, Aug 1, 201
Add a configuration option to /etc/sysconfig/xencommons to let the
user configure whether he wants to start xenstore service as a daemon
or as a stubdom.
Changes in V5:
- patch 2: undo &> to 2> conversion
Changes in V4:
- patch 1: remove sd_booted() test, undo unintended white space changes
- pat
Add configuration entries to sysconfig.xencommons for selection of the
xenstore type (domain or daemon) and start the selected xenstore
service via a script called from sysvinit or systemd.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
V3: - remove check for running xenstore domain, as this
In order to prepare starting a xenstore domain split out the starting
of the xenstore daemon from the xencommons script into a dedicated
launch-xenstore script.
A rerun of autogen.sh is required.
Signed-off-by: Juergen Gross
---
V5: undo &> to 2> conversion
---
.gitignore
On a system with systemd the xenstore sockets are created via systemd.
Remove the related configuration files in order to be able to decide
at runtime whether the sockets should be created or not. This will
enable Xen to start xenstore either via a daemon or via a stub domain.
As the xenstore doma
On Tue, Aug 02, 2016 at 10:49:24AM +0100, Wei Liu wrote:
> On Thu, Jul 28, 2016 at 03:35:19PM +0200, Juergen Gross wrote:
> > libxl_set_memory_target() and several other interface functions of
> > libxl use a 32 bit sized parameter for a memory size value in kBytes.
> > This limits the maximum size
On Mon, Aug 01, 2016 at 10:44:45AM +0100, Ian Jackson wrote:
> Jim Fehlig writes ("[PATCH] docs: define semantics of vncpasswd in xl.cfg"):
> > A recent discussion around LSN-2016-0001 [1] included defining
> > the sematics of an empty string for a VNC password. It was stated
> > that "libxl interp
On Tue, Aug 02, 2016 at 01:17:01PM +0100, Wei Liu wrote:
> On Mon, Aug 01, 2016 at 11:14:27AM -0600, Tamas K Lengyel wrote:
> > Currently mem-sharing can be performed on a page-by-page basis from the
> > control
> > domain. However, this process is quite wasteful when a range of pages have
> > to
Pushed.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Tue, Aug 2, 2016 at 9:23 AM, Tamas K Lengyel
wrote:
> On Aug 2, 2016 06:45, "Jan Beulich" wrote:
>>
>> >>> On 01.08.16 at 18:52, wrote:
>> > --- a/xen/arch/x86/hvm/hvm.c
>> > +++ b/xen/arch/x86/hvm/hvm.c
>> > @@ -1707,7 +1707,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
>> > unsigned long
On 02/08/16 16:48, Tamas K Lengyel wrote:
> On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap
> wrote:
>> On 02/08/16 08:38, Julien Grall wrote:
>>> Hello Tamas,
>>>
>>> On 01/08/2016 21:41, Tamas K Lengyel wrote:
On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall
wrote:
>> we did discuss wh
On Tue, Aug 2, 2016 at 1:38 AM, Julien Grall wrote:
> Hello Tamas,
>
> On 01/08/2016 21:41, Tamas K Lengyel wrote:
>>
>> On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall wrote:
we did discuss whether altp2m on ARM should be exposed to guests or
not but we did not agree whether restrict
On Tue, Aug 2, 2016 at 12:19 AM, sepanta s wrote:
>
>
> On Sat, Jul 23, 2016 at 3:49 PM, sepanta s wrote:
>
>>
Hi,
Is there any sample code which I can undestand how to capture the
events on the gfns which have p2m_ram_shared enabled ?
I couldn't find any ... .
I would b
On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote:
> On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
> > On 29/07/16 17:28, Roger Pau Monne wrote:
> > > diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
> > > index 107fc8c..1b270df 100644
> > > --- a/xen/
On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap wrote:
> On 02/08/16 08:38, Julien Grall wrote:
>> Hello Tamas,
>>
>> On 01/08/2016 21:41, Tamas K Lengyel wrote:
>>> On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall
>>> wrote:
> we did discuss whether altp2m on ARM should be exposed to guests or
>>>
> The level of support you get is somewhat proportional to the amount of money
> you spend.
I shared that comment here, and the immediate follow-on response was:
"Great. Money's not the problem. Which commercial entity provides a supported
solution?"
We're happy to consider Oracle, Redhat, Ub
On Tue, Aug 02, 2016 at 02:14:04PM +0200, Juergen Gross wrote:
> When unplugging a device in the Xen pvusb backend drain the submit
> queue before deallocation of the control structures. Otherwise there
> will be bogus memory accesses when I/O contracts are finished.
>
> Correlated to this issue i
On Aug 2, 2016 06:45, "Jan Beulich" wrote:
>
> >>> On 01.08.16 at 18:52, wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -1707,7 +1707,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
unsigned long gla,
> > int rc, fall_through = 0, paged = 0;
> > int shar
On Aug 2, 2016 06:17, "Wei Liu" wrote:
>
> On Mon, Aug 01, 2016 at 11:14:27AM -0600, Tamas K Lengyel wrote:
> > Currently mem-sharing can be performed on a page-by-page basis from the
control
> > domain. However, this process is quite wasteful when a range of pages
have to
> > be deduplicated.
> >
On 5/27/2016 4:19 PM, Lan Tianyu wrote:
> As for the individual issue of 288vcpu support, there are already issues
> with 64vcpu guests at the moment. While it is certainly fine to remove
> the hard limit at 255 vcpus, there is a lot of other work required to
> even get 128vcpu guests stable.
C
>>> On 02.08.16 at 16:59, wrote:
> On 02/08/16 15:54, Jan Beulich wrote:
> On 02.08.16 at 16:26, wrote:
>>> On 02/08/16 15:17, Jan Beulich wrote:
Well, I find it quite odd for hypercall argument counts to differ
between arches. I.e. I'd conclude the ABI was mis-specified.
>>> Is it
On Tue, Aug 2, 2016, at 07:50 AM, Jan Beulich wrote:
> - one with some suitable variant of reboot=
What exactly is "some suitable variant of reboot" ?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 99897 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99897/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-buildfail like 99891
build-i386-rumpuserxen
On 02/08/16 15:54, Jan Beulich wrote:
On 02.08.16 at 16:26, wrote:
>> On 02/08/16 15:17, Jan Beulich wrote:
>> On 02.08.16 at 16:04, wrote:
On 02/08/16 14:28, Jan Beulich wrote:
On 02.08.16 at 15:14, wrote:
>> On 02/08/16 13:50, Jan Beulich wrote:
>> On 18.07.1
>>> On 02.08.16 at 16:26, wrote:
>
> On 02/08/16 15:17, Jan Beulich wrote:
> On 02.08.16 at 16:04, wrote:
>>> On 02/08/16 14:28, Jan Beulich wrote:
>>> On 02.08.16 at 15:14, wrote:
> On 02/08/16 13:50, Jan Beulich wrote:
> On 18.07.16 at 11:51, wrote:
>>> #include /*
>>> On 02.08.16 at 16:25, wrote:
> On Tue, Aug 2, 2016, at 07:13 AM, Jan Beulich wrote:
>> Unless /mapbs really produces an _exactly_ identical crash, I'd like to
>> see that boot's output at maximum log level. I don't recall "efi=no-rs"
>> having been mentioned before on this thread, but yes, I'd
>>> On 18.07.16 at 02:29, wrote:
> 4.2.2 Detection of Host pmem Devices
>
> The detection and initialize host pmem devices require a non-trivial
> driver to interact with the corresponding ACPI namespace devices,
> parse namespace labels and make necessary recovery actions. Instead
> of dupli
As a followup to the issue below, and the one which "just" popped in in
qemu-2.6+:
Why is the machine description for xen not fixed?
Shouldnt the be some sort of verification of old and new 'xenfv' when a
new qemu rc1 is done?
Is there a way to dump the machine description in text form?
Olaf
On
From: root
These systems use variations of SGI3* for ID string.
Instead of adding abother set of strings do what Linux did
in commit 526018bc and look at first three letters.
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/x86_64/acpi_mmcfg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletio
On 02/08/16 15:17, Jan Beulich wrote:
On 02.08.16 at 16:04, wrote:
On 02/08/16 14:28, Jan Beulich wrote:
On 02.08.16 at 15:14, wrote:
On 02/08/16 13:50, Jan Beulich wrote:
On 18.07.16 at 11:51, wrote:
--- a/xen/include/asm-x86/hypercall.h
+++ b/xen/include/asm-x86/hypercall.h
@@ -5,9 +5
On Tue, Aug 2, 2016, at 07:13 AM, Jan Beulich wrote:
> > You keep stating what you don't see.
>
> Because you keep being vague...
I have attempted to provide everything that's been asked of me.
If you don't like it that's fine. State with specificity what it is you want.
> Unless /mapbs real
>>> On 02.08.16 at 15:58, wrote:
> On Mon, Aug 01, 2016 at 09:21:28AM -0600, Jan Beulich wrote:
>> >>> On 26.07.16 at 17:45, wrote:
>> > Change the message so that it mentions running from the top level directory
>> > and using '-C xen' in order to call the 'menuconfig' target inside of the
>> >
>>> On 02.08.16 at 16:04, wrote:
> On 02/08/16 14:28, Jan Beulich wrote:
> On 02.08.16 at 15:14, wrote:
>>> On 02/08/16 13:50, Jan Beulich wrote:
>>> On 18.07.16 at 11:51, wrote:
> --- a/xen/include/asm-x86/hypercall.h
> +++ b/xen/include/asm-x86/hypercall.h
> @@ -5,9 +5,21 @
>>> On 02.08.16 at 16:06, wrote:
> On 02/08/16 14:12, Jan Beulich wrote:
> On 18.07.16 at 11:51, wrote:
>>> +long pv_hypercall(struct cpu_user_regs *regs)
>>> +{
>>> +struct vcpu *curr = current;
>>> +#ifndef NDEBUG
>>> +unsigned long old_rip = regs->rip;
>>> +#endif
>>> +long ret
On 08/02/2016 03:22 AM, Juergen Gross wrote:
The default for the Xen hypervisor is to not enable VPMU in order to
avoid security issues. In this case the Linux kernel will issue the
message "Could not initialize VPMU for cpu 0, error -95" which looks
more like an error than a normal state.
Cha
On Tue, Aug 02, 2016 at 02:48:54PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v4 2/4] tools: split out xenstored starting form
> xencommons"):
> > On Tue, Aug 02, 2016 at 01:20:40PM +0200, Juergen Gross wrote:
> > > Still confused?
> >
> > Ah, the 2> vs &> thing is really subtle. I m
>>> On 02.08.16 at 15:54, wrote:
>
> On Tue, Aug 2, 2016, at 06:38 AM, Jan Beulich wrote:
>> Well, without going through the _full_ thread again, what I could
>> easily find is
>>
>> "So full console output from boot -> crash now doesn't look any different
>> than
>
>>
>> https://lists
On 08/02/2016 02:53 AM, Juergen Gross wrote:
There are two functions with name xen_pmu_init() in the kernel. Rename
the one in drivers/xen/sys-hypervisor.c to avoid shadowing the one in
arch/x86/xen/pmu.c
To avoid the same problem in future rename some more functions.
Signed-off-by: Juergen G
Hi Wei,
On 08/02/2016 01:59 PM, Wei Liu wrote:
> On Mon, Aug 01, 2016 at 07:10:26PM +0200, Sergej Proskurin wrote:
>> The current implementation allows to set the parameter HVM_PARAM_ALTP2M.
>> This parameter allows further usage of altp2m on ARM. For this, we
>> define an additional, common altp
Copy data operated on during request from/to local buffers to/from
the grant references.
Before grant copy operation local buffers must be allocated what is
done by calling ioreq_init_copy_buffers. For the 'read' operation,
first, the qemu device invokes the read operation on local buffers
and on
Hi,
It is a proposition for implementation of grant copy operation in qemu-qdisk
and interface in libxc/libs.
Changes since v3:
Interface:
- revert to cast from xengnttab_grant_copy_segment_t
to ioctl_gntdev_grant_copy.
- added compile-time check to compare the libs
xengnttab_grant_copy_seg
Hey,
My goal for Xen 4.8 is to get OSSTest to regularly test livepatch mechanism.
I am struggling with OSSTest but I am sure I will figure it out.
But in the meantime I was wondering what the community feels about publishing
step-by-step instructions on how to use livepatching for XSAs. When XSA-
On 02/08/16 14:12, Jan Beulich wrote:
On 18.07.16 at 11:51, wrote:
>> +long pv_hypercall(struct cpu_user_regs *regs)
>> +{
>> +struct vcpu *curr = current;
>> +#ifndef NDEBUG
>> +unsigned long old_rip = regs->rip;
>> +#endif
>> +long ret;
>> +uint32_t eax = regs->eax;
>> +
>>
1 - 100 of 221 matches
Mail list logo
