On 07/08/16 05:31, Tamas K Lengyel wrote:
> This patch implements sending notification to a monitor subscriber when an
> x86/vmx guest executes the CPUID instruction.
>
> Signed-off-by: Tamas K Lengyel
> ---
> Cc: Ian Jackson
> Cc: Wei Liu
> Cc: Razvan Cojocaru
> Cc: Jan Beulich
> Cc: Andrew
>>> On 06.07.16 at 17:50, wrote:
The title of this patch keeps confusing me - which code motion is
being relocated here?
> +void vmx_vm_event_update_cr3_traps(struct domain *d)
Is there anything in this function preventing the parameter to be
const?
> +{
> +struct vcpu *v;
> +struct ar
>>> On 06.07.16 at 17:51, wrote:
> @@ -492,8 +493,12 @@ int vcpu_initialise(struct vcpu *v)
>
> void vcpu_destroy(struct vcpu *v)
> {
> -xfree(v->arch.vm_event);
> -v->arch.vm_event = NULL;
> +if ( unlikely(v->arch.vm_event) )
> +{
> +xfree(v->arch.vm_event->emul_read_d
flight 96778 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96778/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail REGR. vs. 96664
Tests which did not succe
Xen hypervisor drivers might replace native OS drivers. The result is
that some important clocks that are enabled by the OS in the non-Xen
case are not properly enabled in the presence of Xen. The clocks
property enumerates the clocks that must be enabled by the Xen clock
consumer.
An example is a
>>> On 06.07.16 at 17:55, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -31,7 +31,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -63,11 +62,9 @@
> #include
> #include
> #include
> -#include
> #include
> #in
>>> On 07.07.16 at 17:35, wrote:
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1815,7 +1815,7 @@ static struct xsm_operations flask_ops = {
> .xen_version = flask_xen_version,
> };
>
> -__init void flask_init(void)
> +__init void flask_init(const void *policy_buffer, si
>>> On 07.07.16 at 17:35, wrote:
> This adds a Kconfig option and support for including the XSM policy from
> tools/flask/policy in the hypervisor so that the bootloader does not
> need to provide a policy to get sane behavior from an XSM-enabled
> hypervisor. The policy provided by the bootloade
(Re-sending, as I got two bounces)
>>> On 07.07.16 at 17:35, wrote:
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1815,7 +1815,7 @@ static struct xsm_operations flask_ops = {
> .xen_version = flask_xen_version,
> };
>
> -__init void flask_init(void)
> +__init void flas
On 05/07/16 15:28, Corneliu ZUZU wrote:
> The arch_vm_event structure is dynamically allocated and freed @
> vm_event_cleanup_domain. This cleanup is triggered e.g. when the toolstack
> user
> disables domain monitoring (xc_monitor_disable), which in turn effectively
> discards any information tha
At 07:59 + on 06 Jul (1467791951), Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> > Andrew Cooper
> > Sent: 05 July 2016 18:26
> > To: Anthony Perard; xen-devel@lists.xen.org; Jan Beulich
> > Subject: Re: [Xen-devel
Hi Dirk,
On 08/07/16 06:51, Dirk Behme wrote:
On 08.07.2016 04:50, Michael Turquette wrote:
Quoting Dirk Behme (2016-07-07 00:32:34)
The two issues to resolve are:
1) does consuming these hardware resources from the Linux kernel fit
correctly with the Xen model?
I think so. Julien, what do
On 08/07/16 03:31, Tamas K Lengyel wrote:
> This patch implements sending notification to a monitor subscriber when an
> x86/vmx guest executes the CPUID instruction.
>
> Signed-off-by: Tamas K Lengyel
Is it wise having an on/off control without any further filtering? (I
suppose that it is at le
Hi Dirk,
On 08/07/16 08:44, Dirk Behme wrote:
Xen hypervisor drivers might replace native OS drivers. The result is
that some important clocks that are enabled by the OS in the non-Xen
case are not properly enabled in the presence of Xen. The clocks
property enumerates the clocks that must be en
On 08/07/16 07:48, Dirk Behme wrote:
#include
#include
#include
@@ -444,6 +445,52 @@ static int __init xen_pm_init(void)
}
late_initcall(xen_pm_init);
+/*
+ * Check if we want to register some clocks, that they
+ * are not freed because unused by clk_disable_unused().
+ * E.g. the seri
>>> On 05.07.16 at 21:05, wrote:
> In preparation for moving out ACPI builder make all
> BIOSes call hvmloader_acpi_build_tables() instead of
> calling ACPI code directly.
>
> No functional changes.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
___
Hi Wei,
On 07/07/16 16:28, Wei Liu wrote:
On Thu, Jul 07, 2016 at 09:07:59AM -0600, Jan Beulich wrote:
On 07.07.16 at 16:55, wrote:
Cc HV maintainers
I'm of course fine with moving this structure somewhere else.
On Wed, Jun 22, 2016 at 06:15:37PM +0100, Anthony PERARD wrote:
diff --git a/
flight 96783 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96783/
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 Fri, Jun 17, 2016 at 6:32 PM, Dario Faggioli
wrote:
> Hi everyone,
>
> Here you go a collection of pseudo-random fixes and improvement to Credit2.
>
> In the process of working on Soft Affinity and Caps support, I stumbled upon
> them, one after the other, and decided to take care.
>
> It's bee
>>> On 05.07.16 at 21:05, wrote:
> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h
> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
> @@ -449,17 +449,6 @@ struct acpi_20_slit {
> #define ACPI_2_0_SRAT_REVISION 0x01
> #define ACPI_2_0_SLIT_REVISION 0x01
>
> -#pragma pack ()
This must not be remov
>>> On 05.07.16 at 21:05, wrote:
> This way ACPI code won't use xenstore-read() and hvm_param_set()
> which are private to hvmloader.
>
> Signed-off-by: Boris Ostrovsky
> ---
>
> This is one patch that modifies config->ainfo.vm_gid_addr in build.c, with
> that change
> consumed by the caller (
On 07/07/16 14:35, Jan Beulich wrote:
On 07.07.16 at 15:22, wrote:
>> On 07/07/16 14:13, David Vrabel wrote:
>>> On 07/07/16 13:23, Jan Beulich wrote:
>>> On 07.07.16 at 14:17, wrote:
> On 07/07/16 13:09, Jan Beulich wrote:
> On 07.07.16 at 13:36, wrote:
>>> On 07/07/16
On 7/8/2016 10:21 AM, Jan Beulich wrote:
On 06.07.16 at 17:50, wrote:
The title of this patch keeps confusing me - which code motion is
being relocated here?
As the commit message clearly states, the code motions that are being
relocated are:
1) handling of monitor_write_data @ hvm_do_resum
flight 96773 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96773/
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 05.07.16 at 21:05, wrote:
> @@ -890,6 +895,13 @@ void hvmloader_acpi_build_tables(struct acpi_config
> *config,
> config->vm_gid[1] = strtoll(end+1, NULL, 0);
> }
>
> +if ( battery_port_exists() )
> +config->table_flags |= ACPI_BUILD_SSDT_PM;
> +if ( !st
On 7/8/2016 10:35 AM, Jan Beulich wrote:
On 06.07.16 at 17:51, wrote:
@@ -492,8 +493,12 @@ int vcpu_initialise(struct vcpu *v)
void vcpu_destroy(struct vcpu *v)
{
-xfree(v->arch.vm_event);
-v->arch.vm_event = NULL;
+if ( unlikely(v->arch.vm_event) )
+{
+xfree(v->
Hi everyone,
just a quick note that we will perform the following maintenance activities
from July 12. 2016 12:00 UTC to July 13, 2016 9:00 UTC (which is 13:00 BST and
10:00 BST respectively).
The following work will be performed:
- Various HW maintenance activities to the Xen Project Test Infr
On 7/8/2016 10:56 AM, Jan Beulich wrote:
On 06.07.16 at 17:55, wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -63,11 +62,9 @@
#include
#include
#include
-#include
>>> On 08.07.16 at 12:22, wrote:
> On 7/8/2016 10:21 AM, Jan Beulich wrote:
> On 06.07.16 at 17:50, wrote:
>> The title of this patch keeps confusing me - which code motion is
>> being relocated here?
>
> As the commit message clearly states, the code motions that are being
> relocated are:
>>> On 08.07.16 at 12:28, wrote:
> On 7/8/2016 10:35 AM, Jan Beulich wrote:
> On 06.07.16 at 17:51, wrote:
>>> +/* write_data not fully handled, only xfree emul_read_data */
>> Comment style again (and more below).
>
> Ack, assuming you mean 'capital letter, end with dot'.
Actually
Hi Michael and Julien,
On 08.07.2016 11:34, Julien Grall wrote:
Hi Dirk,
On 08/07/16 08:44, Dirk Behme wrote:
Xen hypervisor drivers might replace native OS drivers. The result is
that some important clocks that are enabled by the OS in the non-Xen
case are not properly enabled in the presence
On Thu, Jul 07, 2016 at 05:39:38PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 07/07/16 17:07, Wei Liu wrote:
> >On Tue, Jul 05, 2016 at 11:12:36AM +0800, Shannon Zhao wrote:
> >> int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
> >> libxl__domain_bui
>>> On 05.07.16 at 21:05, wrote:
> Initialize it in hvmloader, avoiding ACPI code's use of xenstore_read()
>
> Signed-off-by: Boris Ostrovsky
> ---
>
> Changes in v1:
> * Rename acpi_pt_length/addr to pt_length/addr
And stopped half way? I ask because ...
> @@ -280,19 +280,11 @@ static int co
On Thu, Jul 07, 2016 at 05:57:09PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 07/07/16 17:15, Wei Liu wrote:
> >On Tue, Jul 05, 2016 at 11:12:47AM +0800, Shannon Zhao wrote:
> >>From: Shannon Zhao
> >>
> >>The guest kernel will get the event channel interrupt information via
> >>domain param HVM
On 08/07/16 11:40, Dirk Behme wrote:
Hi Michael and Julien,
On 08.07.2016 11:34, Julien Grall wrote:
Hi Dirk,
On 08/07/16 08:44, Dirk Behme wrote:
Xen hypervisor drivers might replace native OS drivers. The result is
that some important clocks that are enabled by the OS in the non-Xen
case
On Thu, Jul 07, 2016 at 03:55:23PM +0100, Wei Liu wrote:
> On Wed, Jun 22, 2016 at 06:15:32PM +0100, Anthony PERARD wrote:
> > This patch use xc_dom_alloc_segment() to allocate the memory space for the
> > ACPI modules and the SMBIOS modules. This is to replace the arbitrary
> > placement of 1MB (+
On Tue, Jul 05, 2016 at 03:05:19PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky
> ---
>
> Changes in v1:
> * Move to libxl
> * Added populate_acpi_pages()
> * Stash location/size of tables in xc_dom_image (to be used in constructing
> e820 map)
> * Use libxl allocator
> * Only
On Thu, Jul 07, 2016 at 03:55:29PM +0100, Wei Liu wrote:
> On Wed, Jun 22, 2016 at 06:15:33PM +0100, Anthony PERARD wrote:
> [...]
> > * Allocate and clear additional ioreq server pages. The default
> > * server will use the IOREQ and BUFIOREQ special pages above.
> > @@ -672,6
On 07/07/16 08:25, Jan Beulich wrote:
> 1: don't bail early from xenbus_dev_request_and_reply()
> 2: simplify xenbus_dev_request_and_reply()
Applied to for-linus-4.7b, thanks.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.o
This run is configured for baseline tests only.
flight 66531 xen-unstable running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66531/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvir
This run is configured for baseline tests only.
flight 66543 seabios running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66543/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt
flight 66544 distros-debian-jessie running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66544/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-jessie-netboot-pvgrub queued
This run is configured for baseline tests only.
flight 66532 qemu-mainline running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66532/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvi
On Wed, Jul 06, 2016 at 03:14:15PM +0100, George Dunlap wrote:
> On Mon, Jul 4, 2016 at 7:06 PM, Jan Prunk wrote:
> > Hello !
> >
> > I am posting Xen virtualisation bug links to this e-mail address,
> > because I wasn't able to find the Xen specific bugtracker list.
> > This bug has been discover
Platform Team regression test user writes ("[xen-unstable baseline-only test]
66531: trouble: broken/preparing/queued"):
> This run is configured for baseline tests only.
>
> flight 66531 xen-unstable running [real]
> http://osstest.xs.citrite.net/~osstest/testlogs/logs/66531/
>
> Failures and p
Hi all,
as promised, this is the design document for the XenSock protocol I
mentioned here:
http://marc.info/?l=xen-devel&m=146520572428581
It is still in its early days but should give you a good idea of how it
looks like and how it is supposed to work. Let me know if you find gaps
in the docum
On Fri, Jul 08, 2016 at 11:52:08AM +0100, Anthony PERARD wrote:
> On Thu, Jul 07, 2016 at 03:55:23PM +0100, Wei Liu wrote:
> > On Wed, Jun 22, 2016 at 06:15:32PM +0100, Anthony PERARD wrote:
> > > This patch use xc_dom_alloc_segment() to allocate the memory space for the
> > > ACPI modules and the
On 7/8/2016 1:37 PM, Jan Beulich wrote:
On 08.07.16 at 12:22, wrote:
On 7/8/2016 10:21 AM, Jan Beulich wrote:
On 06.07.16 at 17:50, wrote:
The title of this patch keeps confusing me - which code motion is
being relocated here?
As the commit message clearly states, the code motions that are
Hi Andre,
On 05.07.2016 16:29, Andre Przywara wrote:
Hi,
On 05/07/16 15:22, Dirk Behme wrote:
On 05.07.2016 15:45, Andre Przywara wrote:
Hi,
On 05/07/16 14:34, Julien Grall wrote:
(CC Andre)
On 05/07/16 14:04, Dirk Behme wrote:
On 05.07.2016 14:45, Julien Grall wrote:
On 05/07/16 13:09
On 7/6/2016 6:49 PM, Corneliu ZUZU wrote:
Minor optimization @ vmx_update_guest_cr: checks if v->arch.hvm_vmx.exec_control
was modified before actually calling vmx_update_cpu_exec_control(v).
Signed-off-by: Corneliu ZUZU
---
Changed since v2:
---
xen/arch/x86/hvm/vmx/vmx.c | 5 -
1 file
>>> On 08.07.16 at 13:39, wrote:
> On 7/6/2016 6:49 PM, Corneliu ZUZU wrote:
>> Minor optimization @ vmx_update_guest_cr: checks if
> v->arch.hvm_vmx.exec_control
>> was modified before actually calling vmx_update_cpu_exec_control(v).
>>
>> Signed-off-by: Corneliu ZUZU
>> ---
>> Changed since v2
>>> On 08.07.16 at 13:33, wrote:
> On 7/8/2016 1:37 PM, Jan Beulich wrote:
> On 08.07.16 at 12:22, wrote:
>>> On 7/8/2016 10:21 AM, Jan Beulich wrote:
>>> On 06.07.16 at 17:50, wrote:
> +/*
> + * If CR0.PE=0, CR3 load exiting must remain enabled.
> + *
On 7/8/2016 2:48 PM, Jan Beulich wrote:
On 08.07.16 at 13:39, wrote:
On 7/6/2016 6:49 PM, Corneliu ZUZU wrote:
Minor optimization @ vmx_update_guest_cr: checks if
v->arch.hvm_vmx.exec_control
was modified before actually calling vmx_update_cpu_exec_control(v).
Signed-off-by: Corneliu ZUZU
On 7/8/2016 2:53 PM, Jan Beulich wrote:
On 08.07.16 at 13:33, wrote:
On 7/8/2016 1:37 PM, Jan Beulich wrote:
On 08.07.16 at 12:22, wrote:
On 7/8/2016 10:21 AM, Jan Beulich wrote:
On 06.07.16 at 17:50, wrote:
+/*
+ * If CR0.PE=0, CR3 load exiting must remain enabled.
+
>>> On 08.07.16 at 13:55, wrote:
> On 7/8/2016 2:48 PM, Jan Beulich wrote:
> On 08.07.16 at 13:39, wrote:
>>> On 7/6/2016 6:49 PM, Corneliu ZUZU wrote:
Minor optimization @ vmx_update_guest_cr: checks if
>>> v->arch.hvm_vmx.exec_control
was modified before actually calling vmx_updat
On 08/07/16 13:23, Stefano Stabellini wrote:
> Hi all,
>
> as promised, this is the design document for the XenSock protocol I
> mentioned here:
>
> http://marc.info/?l=xen-devel&m=146520572428581
>
> It is still in its early days but should give you a good idea of how it
> looks like and how it
As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
CPUID[0x8007].EDX[7] anymore, causing the driver to fail to load on
both Intel and AMD systems. Doing any kind of hardware capability
checks in the driver as a prerequisite was wrong anyway: With the
hypervisor being in charge,
On Wed, Jun 29, 2016 at 03:00:41PM +0200, Juergen Gross wrote:
> On 29/06/16 14:52, Andrew Cooper wrote:
> > On 29/06/16 13:44, Juergen Gross wrote:
> >> @@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
> >>/* Tell the kernel we're up and running. */
> >>xenbus_notify_running();
> >>
On 7/6/2016 6:49 PM, Corneliu ZUZU wrote:
Minor optimization @ vmx_update_guest_cr: checks if v->arch.hvm_vmx.exec_control
was modified before actually calling vmx_update_cpu_exec_control(v).
Signed-off-by: Corneliu ZUZU
---
Changed since v2:
---
xen/arch/x86/hvm/vmx/vmx.c | 5 -
1 file
flight 96776 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96776/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR.
vs. 96732
Regressio
For single items being collected this should be preferred as being more
typesafe (as the compiler can check format string and to-be-written-to
variable match) and more efficient (requiring one less parameter to be
passed).
1: xenbus: prefer xenbus_scanf() over xenbus_gather()
2: xen-blkback: prefe
Hello,
Please also send a CC: to 804...@bugs.debian.org for future reference.
The administrator of the server is Andreas Ziegler ,
maybe he will be able to log/reproduce the bug, I was only an initial
reporter.
Kind regards,
Jan
On Fri, Jul 8, 2016 at 1:14 PM, Wei Liu wrote:
> On Wed, Jul 06,
For single items being collected this should be preferred as being more
typesafe (as the compiler can check format string and to-be-written-to
variable match) and more efficient (requiring one less parameter to be
passed).
Signed-off-by: Jan Beulich
---
v2: Avoid commit message to continue from s
For single items being collected this should be preferred as being more
typesafe (as the compiler can check format string and to-be-written-to
variable match) and more efficient (requiring one less parameter to be
passed).
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v2: Avoid commit
For single items being collected this should be preferred as being more
typesafe (as the compiler can check format string and to-be-written-to
variable match) and more efficient (requiring one less parameter to be
passed).
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v2: Avoid commit
For single items being collected this should be preferred as being more
typesafe (as the compiler can check format string and to-be-written-to
variable match) and more efficient (requiring one less parameter to be
passed).
Signed-off-by: Jan Beulich
---
v2: Avoid commit message to continue from s
On 08/07/16 13:15, Jan Beulich wrote:
> As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
> CPUID[0x8007].EDX[7] anymore, causing the driver to fail to load on
> both Intel and AMD systems. Doing any kind of hardware capability
> checks in the driver as a prerequisite was wron
On 08/07/16 14:15, Wei Liu wrote:
> On Wed, Jun 29, 2016 at 03:00:41PM +0200, Juergen Gross wrote:
>> On 29/06/16 14:52, Andrew Cooper wrote:
>>> On 29/06/16 13:44, Juergen Gross wrote:
@@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
/* Tell the kernel we're up and running. */
>>> On 08.07.16 at 14:29, wrote:
> On 08/07/16 13:15, Jan Beulich wrote:
>> As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
>> CPUID[0x8007].EDX[7] anymore, causing the driver to fail to load on
>> both Intel and AMD systems. Doing any kind of hardware capability
>> checks
flight 96790 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96790/
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 Fri, Jul 08, 2016 at 02:32:31PM +0200, Juergen Gross wrote:
> On 08/07/16 14:15, Wei Liu wrote:
> > On Wed, Jun 29, 2016 at 03:00:41PM +0200, Juergen Gross wrote:
> >> On 29/06/16 14:52, Andrew Cooper wrote:
> >>> On 29/06/16 13:44, Juergen Gross wrote:
> @@ -2068,13 +1964,6 @@ int main(int
On 07/07/16 18:17, Lars Kurth wrote:
> Alright,
>
> it appears we are at an impasse here. Not hosting the code on xenbits as
> suggested by David, seems to be the worst solution and will benefit
> no-one.
>
>> If we can't get consensus on something like this, the sensible thing
>> to do would be t
To unblock Paulina on her series, I would be ok with the cast provided
there is compile-time check to ensure the user-space structure is
identical to the ioctl structure.
That would involve:
1. Introducing BUILD_BUG_ON, offsetof, alignof to libs/ if they are not
already available.
2. BUILD_BUG_
On Fri, Jul 08, 2016 at 12:29:36PM +0100, Wei Liu wrote:
> On Fri, Jul 08, 2016 at 11:52:08AM +0100, Anthony PERARD wrote:
> > On Thu, Jul 07, 2016 at 03:55:23PM +0100, Wei Liu wrote:
> > > On Wed, Jun 22, 2016 at 06:15:32PM +0100, Anthony PERARD wrote:
> > > > diff --git a/tools/libxc/xc_dom_hvmlo
>>> On 05.07.16 at 21:05, wrote:
> No need for ACPI code to rely on hvm_info.
Perhaps better "... on the hvm_info variable"?
> @@ -118,9 +118,9 @@ static struct acpi_20_madt *construct_madt(struct
> acpi_info *info)
> io_apic->ioapic_addr = IOAPIC_BASE_ADDRESS;
>
> lapic = (struct a
>>> On 05.07.16 at 21:05, wrote:
> @@ -79,6 +80,8 @@ struct acpi_config {
> struct acpi_numa numa;
> struct hvm_info_table *hvminfo;
>
> +uint16_t *tis_hdr;
const?
With that adjusted (unless impossible)
Reviewed-by: Jan Beulich
___
X
>>> On 05.07.16 at 21:05, wrote:
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 08/07/2016 14:06, "Andrew Cooper" wrote:
>On 07/07/16 18:17, Lars Kurth wrote:
>> Alright,
>>
>> it appears we are at an impasse here. Not hosting the code on xenbits as
>> suggested by David, seems to be the worst solution and will benefit
>> no-one.
>>
>>...
>> That should address everyon
>>> On 05.07.16 at 21:05, wrote:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -342,9 +342,12 @@ static int construct_secondary_tables(unsigned long
> *table_ptrs,
> }
>
> /* WAET. */
> -waet = construct_waet();
> -if (!waet)
On 08/07/16 14:42, Lars Kurth wrote:
>
> On 08/07/2016 14:06, "Andrew Cooper" wrote:
>
>> On 07/07/16 18:17, Lars Kurth wrote:
>>> Alright,
>>>
>>> it appears we are at an impasse here. Not hosting the code on xenbits as
>>> suggested by David, seems to be the worst solution and will benefit
>>> n
On 08/07/16 13:53, Jan Beulich wrote:
On 08.07.16 at 14:29, wrote:
>> On 08/07/16 13:15, Jan Beulich wrote:
>>> As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
>>> CPUID[0x8007].EDX[7] anymore, causing the driver to fail to load on
>>> both Intel and AMD systems. Doing
On Thu, Jul 07, 2016 at 09:57:10AM -0600, Jan Beulich wrote:
> >>> On 07.07.16 at 17:37, wrote:
> > On Thu, Jul 07, 2016 at 10:52:18AM +0100, Andrew Cooper wrote:
> >> On 07/07/16 10:45, Roger Pau Monne wrote:
> >> > On Thu, Jul 07, 2016 at 01:38:58AM -0600, Jan Beulich wrote:
> >> >> The function
>>> On 05.07.16 at 21:05, wrote:
> Components that wish to use ACPI builder will need to provide their own
> mem_alloc() and virt_to_phys() routines. Pointers to these routines will
> be passed to the builder as memory ops.
>
> Signed-off-by: Boris Ostrovsky
> ---
>
> Changes in v1:
> * Keep me
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.7b-rc6-tag
xen: bug fixes for 4.7-rc6
- Fix two bugs in the handling of xenbus transactions.
- Make the xen acpi driver compatible with Xen 4.7.
Thanks.
David
drivers/xen/xen-ac
Hi Juergen,
many thanks for the fast and very useful review!
On Fri, 8 Jul 2016, Juergen Gross wrote:
> On 08/07/16 13:23, Stefano Stabellini wrote:
> > Hi all,
> >
> > as promised, this is the design document for the XenSock protocol I
> > mentioned here:
> >
> > http://marc.info/?l=xen-devel
On Fri, Jul 08, 2016 at 06:21:52AM -0600, Jan Beulich wrote:
> For single items being collected this should be preferred as being more
> typesafe (as the compiler can check format string and to-be-written-to
> variable match) and more efficient (requiring one less parameter to be
> passed).
>
> 1:
On 08/07/16 16:16, Stefano Stabellini wrote:
> Hi Juergen,
>
> many thanks for the fast and very useful review!
>
>
> On Fri, 8 Jul 2016, Juergen Gross wrote:
>> On 08/07/16 13:23, Stefano Stabellini wrote:
>>> #define XENSOCK_DATARING_ORDER 6
>>> #define XENSOCK_DATARING_PAGES (1 << XEN
>>> On 05.07.16 at 21:05, wrote:
> Non-hvmloader users may be building tables in virtual address space
> and therefore we need to make sure that values that end up in tables
> are physical addresses.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
On 07/08/2016 06:10 AM, Jan Beulich wrote:
>
>> @@ -615,20 +593,10 @@ void acpi_build_tables(struct acpi_config *config,
>> unsigned int physical)
>> offsetof(struct acpi_20_rsdp, extended_checksum),
>> sizeof(struct acpi_20_rsdp));
>>
>> -if ( !new_vm_gid
On 07/08/2016 06:55 AM, Wei Liu wrote:
>
>> +
>> +/* Map page that will hold RSDP */
>> +extent = RSDP_ADDRESS >> ctxt.page_shift;
>> +rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
>> +if (rc) {
>> +LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
>> +
>>> On 05.07.16 at 21:05, wrote:
> @@ -95,7 +96,15 @@ all: subdirs-all
> ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
> smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
>
> -hvmloader: $(OBJS) acpi/acpi.a
> +ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
I think I did
>>> On 08.07.16 at 16:17, wrote:
> On Fri, Jul 08, 2016 at 06:21:52AM -0600, Jan Beulich wrote:
>> For single items being collected this should be preferred as being more
>> typesafe (as the compiler can check format string and to-be-written-to
>> variable match) and more efficient (requiring one
On Thu, Jul 07, 2016 at 01:45:05PM -0400, Boris Ostrovsky wrote:
> On 07/07/2016 01:15 PM, Wei Liu wrote:
> > On Thu, Jul 07, 2016 at 01:09:28PM -0400, Boris Ostrovsky wrote:
> >> On 07/07/2016 12:58 PM, Ian Jackson wrote:
> >>> There are two serious problems with this.
> >>>
> >>> 1. You have drop
On 07/08/2016 09:36 AM, Jan Beulich wrote:
>
>> @@ -51,6 +53,14 @@ struct acpi_info {
>> uint64_t pci_hi_min, pci_hi_len; /* 24, 32 - PCI I/O hole boundaries */
>> };
>>
>> +struct acpi_numa {
>> +uint32_t nr_vmemranges;
>> +uint32_t nr_vnodes;
>> +unsigned int *vcpu_to_vnode;
>
>>> On 08.07.16 at 16:39, wrote:
> On 07/08/2016 06:10 AM, Jan Beulich wrote:
>>
>>> @@ -615,20 +593,10 @@ void acpi_build_tables(struct acpi_config *config,
> unsigned int physical)
>>> offsetof(struct acpi_20_rsdp, extended_checksum),
>>> sizeof(struct acpi_2
>>> On 08.07.16 at 17:08, wrote:
> On 07/08/2016 09:36 AM, Jan Beulich wrote:
>>> @@ -51,6 +53,14 @@ struct acpi_info {
>>> @@ -66,6 +76,9 @@ struct acpi_config {
>>> uint32_t pt_length;
>>> } pt;
>>>
>>> +struct acpi_numa numa;
>> ... right here, perhaps even omitting the stru
On Fri, Jul 08, 2016 at 09:06:36AM -0600, Jan Beulich wrote:
> >>> On 08.07.16 at 16:17, wrote:
> > On Fri, Jul 08, 2016 at 06:21:52AM -0600, Jan Beulich wrote:
> >> For single items being collected this should be preferred as being more
> >> typesafe (as the compiler can check format string and t
On 07/08/2016 09:58 AM, Jan Beulich wrote:
On 05.07.16 at 21:05, wrote:
>> Components that wish to use ACPI builder will need to provide their own
>> mem_alloc() and virt_to_phys() routines. Pointers to these routines will
>> be passed to the builder as memory ops.
>>
>> Signed-off-by: Boris
>>> On 08.07.16 at 17:23, wrote:
> On 07/08/2016 09:58 AM, Jan Beulich wrote:
> On 05.07.16 at 21:05, wrote:
>>> Components that wish to use ACPI builder will need to provide their own
>>> mem_alloc() and virt_to_phys() routines. Pointers to these routines will
>>> be passed to the builder as
On Fri, Jul 8, 2016 at 1:03 AM, Razvan Cojocaru
wrote:
> On 07/08/16 05:31, Tamas K Lengyel wrote:
>> This patch implements sending notification to a monitor subscriber when an
>> x86/vmx guest executes the CPUID instruction.
>>
>> Signed-off-by: Tamas K Lengyel
>> ---
>> Cc: Ian Jackson
>> Cc:
1 - 100 of 218 matches
Mail list logo
