On 17-01-09 09:26:17, Wei Liu wrote:
> On Mon, Jan 09, 2017 at 01:31:35AM -0700, Jan Beulich wrote:
> > >>> On 09.01.17 at 02:19, wrote:
> > > On 17-01-06 12:04:36, Wei Liu wrote:
> > >> On Wed, Dec 14, 2016 at 12:08:01PM +0800, Yi Sun wrote:
> > >> > This patch implements xl/xc changes to support
On 01/05/2017 10:56 PM, Jan Beulich wrote:
On 31.12.16 at 06:45, wrote:
Since vlapic_init() is called before vcpu_initialise().
We should call the destroy functions in the the reverse order here.
Double "the". And to quote from my RFC reply:
"Also the ordering issue extends to other calls,
>>> On 10.01.17 at 02:24, wrote:
> On 12/7/16 7:18 AM, Jan Beulich wrote:
> On 05.12.16 at 23:25, wrote:
>>> ..nor EFI platforms with runtime services enabled.
>>
>> Btw, was the title meant to read "... neither on non-EFI platforms ..."?
>
> Could we reduce the amount of negatives?
>
> "d
>>> On 10.01.17 at 07:57, wrote:
> On 01/05/2017 10:53 PM, Jan Beulich wrote:
> On 31.12.16 at 06:45, wrote:
>>> Expose vlapic_read_aligned and vlapic_reg_write() to be used by AVIC.
>>>
>>> Signed-off-by: Suravee Suthikulpanit
>>> Reviewed-by: Konrad Rzeszutek Wilk
>>
>> Generally I dislik
>>> On 10.01.17 at 07:51, wrote:
> On 01/05/2017 10:51 PM, Jan Beulich wrote:
> On 31.12.16 at 06:45, wrote:
>>> --- a/xen/include/asm-x86/hvm/domain.h
>>> +++ b/xen/include/asm-x86/hvm/domain.h
>>> @@ -72,6 +72,67 @@ struct hvm_ioreq_server {
>>> bool_t bufioreq_atomic;
Jan,
On 01/05/2017 11:05 PM, Jan Beulich wrote:
On 31.12.16 at 06:46, wrote:
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1438,6 +1438,11 @@ static int svm_cpu_up(void)
return 0;
}
+static inline int svm_avic_enabled(void)
bool?
Actually, I declared this as
>>> On 10.01.17 at 02:21, wrote:
> On 12/5/16 4:25 PM, Daniel Kiper wrote:
>> +/* Flags set in the 'flags' member of the multiboot header. */
>> +#define MULTIBOOT2_TAG_TYPE_END 0
>> +#define MULTIBOOT2_TAG_TYPE_CMDLINE 1
>> +#define MULTIBOOT2_TAG_TYPE
flight 104093 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104093/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104076
test-armhf-armhf-libvirt-qcow2 1
>>> On 10.01.17 at 09:00, wrote:
> On 17-01-09 09:26:17, Wei Liu wrote:
>> On Mon, Jan 09, 2017 at 01:31:35AM -0700, Jan Beulich wrote:
>> > >>> On 09.01.17 at 02:19, wrote:
>> > > On 17-01-06 12:04:36, Wei Liu wrote:
>> > >> On Wed, Dec 14, 2016 at 12:08:01PM +0800, Yi Sun wrote:
>> > >> > This
>>> On 10.01.17 at 07:34, wrote:
> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -226,6 +226,7 @@ XEN_CPUFEATURE(PREFETCHWT1, 6*32+ 0) /*A PREFETCHWT1
> instruction */
> XEN_CPUFEATURE(AVX512VBMI,6*32+ 1) /*A AVX-512 Vector Byt
The versioning of the series was chosen based on the oldest patch;
most of the patches here would effectively be v1 or some other
lower numbered one.
1: support CLWB
2: correct EFLAGS.TF handling
3: conditionally clear BNDn for branches
4: support VME and PVI
5: use switch()-wide local variable 'c
On Tue, Jan 10, 2017 at 01:49:06AM -0700, Jan Beulich wrote:
> >>> On 10.01.17 at 07:34, wrote:
> > --- a/xen/include/public/arch-x86/cpufeatureset.h
> > +++ b/xen/include/public/arch-x86/cpufeatureset.h
> > @@ -226,6 +226,7 @@ XEN_CPUFEATURE(PREFETCHWT1, 6*32+ 0) /*A PREFETCHWT1
> > instructi
>>> On 10.01.17 at 09:35, wrote:
> On 01/05/2017 11:05 PM, Jan Beulich wrote:
> On 31.12.16 at 06:46, wrote:
>>> --- a/xen/arch/x86/hvm/svm/svm.c
>>> +++ b/xen/arch/x86/hvm/svm/svm.c
>>> @@ -1438,6 +1438,11 @@ static int svm_cpu_up(void)
>>> return 0;
>>> }
>>>
>>> +static inline int sv
On 17-01-10 01:46:17, Jan Beulich wrote:
> >>> On 10.01.17 at 09:00, wrote:
> > On 17-01-09 09:26:17, Wei Liu wrote:
> >> On Mon, Jan 09, 2017 at 01:31:35AM -0700, Jan Beulich wrote:
> >> > >>> On 09.01.17 at 02:19, wrote:
> >> > > On 17-01-06 12:04:36, Wei Liu wrote:
> >> > >> On Wed, Dec 14, 20
Just like for CLFLUSH{,OPT} back it by the wbinvd() hook for now.
Signed-off-by: Jan Beulich
---
This was really meant to go together with the fencing insns enabling.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1309,6 +1309,7 @@ static bool vcpu_
For repeated string instructions we should not emulate multiple
iterations in one go when a single step trap needs injecting (which
needs to happen after every iteration).
For all non-branch instructions as well as not taken conditional
branches we additionally need to take DebugCtl.BTF into consi
Considering that we surface MPX to HVM guests, instructions we emulate
should also correctly deal with MPX state. While for now BND*
instructions don't get emulated, the effect of branches (which we do
emulate) without BND prefix should be taken care of.
No need to alter XABORT behavior: While not
On 01/09/2017 02:54 PM, Andrew Cooper wrote:
> On 09/01/17 11:36, Razvan Cojocaru wrote:
>> Hello,
>>
>> We've come across a weird phenomenon: an Ubuntu 16.04.1 LTS HVM guest
>> running kernel 4.4.0 installed via XenCenter in XenServer Dundee seems
>> to eat up all the RAM it can:
>>
>> (XEN) [ 39
... rather than various smaller scope ones.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -862,13 +862,10 @@ do {
#define put_fpu(_fic) \
do {
... affecting POPF, CLI, and STI.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -433,6 +433,8 @@ typedef union {
#define CR0_EM(1<<2)
#define CR0_TS(1<<3)
+#define CR4_VME(1<<0)
+#define CR4_PVI
- don't accept LOCK for DR accesses (it's undefined in the manuals)
- only accept LOCK for CR accesses when the respective feature flag is
set (which would not normally be the case for Intel)
- add (rather than or) 8 when LOCK is present; real hardware #UDs
when both REX.W and LOCK are present,
flight 104095 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104095/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fca422890777a02c027061fbceee454c9f117870
baseline version:
ovmf 7ecfa0aa38a3601c958a8
AVX512_VPOPCNTDQ: Vector POPCNT instructions for word and qwords.
variable precision.
Signed-off-by: He Chen
---
Changes from v1:
renanme VPOPCNTDQ to AVX512_VPOPCNTDQ.
---
xen/include/public/arch-x86/cpufeatureset.h | 1 +
xen/tools/gen-cpuid.py | 3 ++-
2 files changed, 3
>>> On 10.01.17 at 10:19, wrote:
> AVX512_VPOPCNTDQ: Vector POPCNT instructions for word and qwords.
> variable precision.
>
> Signed-off-by: He Chen
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org
On 01/09/2017 02:54 PM, Andrew Cooper wrote:
> On 09/01/17 11:36, Razvan Cojocaru wrote:
>> Hello,
>>
>> We've come across a weird phenomenon: an Ubuntu 16.04.1 LTS HVM guest
>> running kernel 4.4.0 installed via XenCenter in XenServer Dundee seems
>> to eat up all the RAM it can:
>>
>> (XEN) [ 39
On 01/10/2017 03:24 PM, Jan Beulich wrote:
On 10.01.17 at 07:51, wrote:
On 01/05/2017 10:51 PM, Jan Beulich wrote:
On 31.12.16 at 06:45, wrote:
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -72,6 +72,67 @@ struct hvm_ioreq_server {
bool_t
On Mon, Jan 09, 2017 at 04:37:53PM +, Ian Jackson wrote:
> Eric DeVolder writes ("[PATCH] convert tabs into spaces; preserving
> indentation"):
> > Convert tabs into spaces; preserving indentation
> >
> > No functional changes
> >
> > Signed-off-by: Eric DeVolder
>
> Acked-by: Ian Jackson
On Tue, Jan 10, 2017 at 02:26:50AM -0700, Jan Beulich wrote:
> >>> On 10.01.17 at 10:19, wrote:
> > AVX512_VPOPCNTDQ: Vector POPCNT instructions for word and qwords.
> > variable precision.
> >
> > Signed-off-by: He Chen
>
> Reviewed-by: Jan Beulich
>
Acked + applied.
__
On 01/10/2017 04:00 PM, Jan Beulich wrote:
On 10.01.17 at 09:35, wrote:
On 01/05/2017 11:05 PM, Jan Beulich wrote:
On 31.12.16 at 06:46, wrote:
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1438,6 +1438,11 @@ static int svm_cpu_up(void)
return 0;
}
+static in
On Mon, Jan 09, 2017 at 04:36:41PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v2] get_maintainer.pl: Teach brace expansion"):
> > It is done by using two different regex, the first one will take care of
> > converting ',' inside '{}' to a '|', one by one, as long as there is at
> >
On Mon, Jan 9, 2017 at 4:39 PM, Olaf Hering wrote:
> On Mon, Jan 09, Ian Jackson wrote:
>
>> Olaf Hering writes ("[PATCH qemu-xen-traditional 2/2] xen_platform: SUSE
>> xenlinux unplug for emulated PCI"):
>> > From: Olaf Hering
>> >
>> > Implement SUSE specific unplug protocol for emulated PCI d
On Mon, Jan 09, 2017 at 05:24:14PM +0100, Juergen Gross wrote:
> On 09/01/17 15:39, Jan Beulich wrote:
> > Commit 9e49dcf67f ("xenstore: add per-node generation counter) changed
> > the TDB layout, which - in order to not break older xenstored running
> > on the same system - need to be accompanied
Jan,
On 01/05/2017 11:07 PM, Jan Beulich wrote:
On 31.12.16 at 06:46, wrote:
+void __init setup_avic_dump(void)
+{
+register_keyhandler('j', avic_dump, "dump SVM AVIC", 1);
+}
For one the description should include the word "stats". And then
I'm rather uncertain this is work burning one
flight 104096 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104096/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 363dc42226a1d8ae02c73f9dd81da65af91b5fdd
baseline version:
ovmf fca422890777a02c02706
On 10/01/17 09:02, Jan Beulich wrote:
> Just like for CLFLUSH{,OPT} back it by the wbinvd() hook for now.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
From: "Edgar E. Iglesias"
Relax the hardware domains mapping attributes to p2m_mmio_direct_c.
This will allow the hardware domain to fully control the
attribtues via its S1 mappings.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/domain_build.c | 63 ++---
From: "Edgar E. Iglesias"
This relaxes the hw domains S2 mapping attributes to p2m_mmio_direct_c.
Eventually, I think we should allow guests to execute code from on chip
memories. We could follow-up with a patch that allows execution for
p2m_mmio_direct_c and p2m_mmio_direct_nc. Does that sound
Hi Stefano,
On 7 January 2017 at 03:24, Stefano Stabellini wrote:
> Hello Bhupinder,
>
> it is good to hear that you are making progress.
>
>
> On Fri, 6 Jan 2017, Bhupinder Thakur wrote:
>> Hi,
>>
>> I am trying to allocate a new SPI VIRQ for sending pl011 interrupt to
>> the guest OS. Current
On 10/01/17 09:03, Jan Beulich wrote:
> For repeated string instructions we should not emulate multiple
> iterations in one go when a single step trap needs injecting (which
> needs to happen after every iteration).
>
> For all non-branch instructions as well as not taken conditional
> branches we
>>> On 14.12.16 at 05:07, wrote:
> @@ -141,11 +144,79 @@ struct psr_assoc {
>
> struct psr_cmt *__read_mostly psr_cmt;
>
> +static struct psr_socket_info *__read_mostly socket_info;
> +
> static unsigned int opt_psr;
> static unsigned int __initdata opt_rmid_max = 255;
> +static unsigned in
On 10/01/17 09:05, Jan Beulich wrote:
> ... rather than various smaller scope ones.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 10/01/17 09:06, Jan Beulich wrote:
> - don't accept LOCK for DR accesses (it's undefined in the manuals)
> - only accept LOCK for CR accesses when the respective feature flag is
> set (which would not normally be the case for Intel)
> - add (rather than or) 8 when LOCK is present; real hardwar
flight 104094 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104094/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt 17 guest-start/debian.repeat fail in 104090 pass in
104094
test-armhf-armhf-xl-credit
On Wed, Jan 04, 2017 at 02:30:50PM -0800, Florian Fainelli wrote:
> On 01/04/2017 03:44 AM, Will Deacon wrote:
> > On Tue, Jan 03, 2017 at 03:25:53PM -0800, Laura Abbott wrote:
> >> On 01/03/2017 02:56 PM, Florian Fainelli wrote:
> >>> On 01/03/2017 09:21 AM, Laura Abbott wrote:
> Happy New Ye
>>> On 10.01.17 at 12:14, wrote:
> On 01/05/2017 11:07 PM, Jan Beulich wrote:
> On 31.12.16 at 06:46, wrote:
>>> +void __init setup_avic_dump(void)
>>> +{
>>> +register_keyhandler('j', avic_dump, "dump SVM AVIC", 1);
>>> +}
>>
>> For one the description should include the word "stats". An
flight 104097 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104097/
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 1
>>> On 10.01.17 at 12:59, wrote:
> On 10/01/17 09:06, Jan Beulich wrote:
>> - don't accept LOCK for DR accesses (it's undefined in the manuals)
>> - only accept LOCK for CR accesses when the respective feature flag is
>> set (which would not normally be the case for Intel)
>> - add (rather than
This run is configured for baseline tests only.
flight 68351 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68351/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fca422890777a02c027061fbceee454c9f117870
baseline v
The default for the number of tx/rx queues of one interface is the
number of vcpus of the system today. As each queue pair reserves 512
grant pages this default consumes a ridiculous number of grants for
large guests.
Limit the queue number to 8 as default. This value can be modified
via a module
The default for the maximum number of tx/rx queues of one interface is
the number of cpus of the system today. As each queue pair reserves 512
grant pages this default consumes a ridiculous number of grants for
large guests.
Limit the queue number to 8 as default. This value can be modified
via a
The Xen network frontend/backend supports multiple tx/rx queues for one
virtual interface. The number of queues supported by the backend is
set to the number of cpus of the backend driver domain (usually dom0)
and the number of queues requested by the frontend is limited by the
number of vcpus of t
>>> On 14.12.16 at 05:07, wrote:
> @@ -358,11 +366,32 @@ void psr_free_rmid(struct domain *d)
> d->arch.psr_rmid = 0;
> }
>
> +static inline unsigned int get_max_cos_max(const struct psr_socket_info
> *info)
> +{
> +const struct feat_node *feat_tmp;
Same remark as on the earlier patc
>>> On 14.12.16 at 05:07, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -115,6 +115,9 @@ struct feat_ops {
> struct psr_socket_info *info);
> /* get_max_cos_max is used to get feature's cos_max. */
> unsigned int (*get_max_cos_max)(const stru
>>> On 14.12.16 at 05:07, wrote:
> This patch implements get value flow including L3 CAT callback
> function.
>
> It also changes domctl interface to make it more general.
>
> With this patch, 'psr-cat-show' can work for L3 CAT.
How about CDP? You don't implement anything for it here, and looki
On Tue, Jan 10, 2017 at 02:32:50PM +0100, Juergen Gross wrote:
> The Xen network frontend/backend supports multiple tx/rx queues for one
> virtual interface. The number of queues supported by the backend is
> set to the number of cpus of the backend driver domain (usually dom0)
> and the number of
The order of destroy function calls in hvm_vcpu_destroy() should be
the reverse of init calls in hvm_vcpu_initialise().
Signed-off-by: Suravee Suthikulpanit
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Kevin Tian
Cc: Jan Beulich
Cc: Boris Ostrovsky
---
Note: I separate this out from the pr
> To make the set value flow be general and can support multiple features
> at same time, it includes below steps:
> 1. Get COS ID of current domain using.
> 2. Assemble a value array to store all features current value
>in it and replace the current value of the feature which is
>being set
On 10/01/17 09:06, Razvan Cojocaru wrote:
> On 01/09/2017 02:54 PM, Andrew Cooper wrote:
>> On 09/01/17 11:36, Razvan Cojocaru wrote:
>>> Hello,
>>>
>>> We've come across a weird phenomenon: an Ubuntu 16.04.1 LTS HVM guest
>>> running kernel 4.4.0 installed via XenCenter in XenServer Dundee seems
>
On 10/01/17 14:03, Suravee Suthikulpanit wrote:
> The order of destroy function calls in hvm_vcpu_destroy() should be
> the reverse of init calls in hvm_vcpu_initialise().
>
> Signed-off-by: Suravee Suthikulpanit
> Reviewed-by: Konrad Rzeszutek Wilk
> Reviewed-by: Kevin Tian
> Cc: Jan Beulich
>
On 10/01/17 14:15, Andrew Cooper wrote:
> On 10/01/17 14:03, Suravee Suthikulpanit wrote:
>> The order of destroy function calls in hvm_vcpu_destroy() should be
>> the reverse of init calls in hvm_vcpu_initialise().
>>
>> Signed-off-by: Suravee Suthikulpanit
>> Reviewed-by: Konrad Rzeszutek Wilk
>>> On 14.12.16 at 05:07, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -121,6 +121,35 @@ struct feat_ops {
> /* get_val is used to get feature COS register value. */
> bool (*get_val)(const struct feat_node *feat, unsigned int cos,
> enum cbm_type
>>> On 10.01.17 at 15:26, wrote:
> On 10/01/17 14:15, Andrew Cooper wrote:
>> On 10/01/17 14:03, Suravee Suthikulpanit wrote:
>>> The order of destroy function calls in hvm_vcpu_destroy() should be
>>> the reverse of init calls in hvm_vcpu_initialise().
>>>
>>> Signed-off-by: Suravee Suthikulpanit
>>> On 14.12.16 at 05:07, wrote:
> Continue with previous patch, we can try to find if there is a
Please take into consideration that a series may be applied in small
steps. References such as "previous patch" are thus possibly
meaningless. Please instead refer to the patch by title. Also I think
On 01/10/2017 08:32 AM, Juergen Gross wrote:
> The default for the number of tx/rx queues of one interface is the
> number of vcpus of the system today. As each queue pair reserves 512
> grant pages this default consumes a ridiculous number of grants for
> large guests.
>
> Limit the queue number t
On Wed, Jan 04, 2017 at 08:52:00PM +0100, Laszlo Ersek wrote:
> On 12/08/16 16:33, Anthony PERARD wrote:
> > Hi,
> >
> > I've started to create a Xen specifig plaform, in OvmfPkg/XenOvmf.dsc
> > with the goal to make it work on both Xen HVM and Xen PVHv2
>
> Does this mean we can ultimately move
On 01/10/2017 04:13 PM, Andrew Cooper wrote:
> On 10/01/17 09:06, Razvan Cojocaru wrote:
>> On 01/09/2017 02:54 PM, Andrew Cooper wrote:
>>> On 09/01/17 11:36, Razvan Cojocaru wrote:
Hello,
We've come across a weird phenomenon: an Ubuntu 16.04.1 LTS HVM guest
running kernel 4.4.
On 10/01/17 15:53, Boris Ostrovsky wrote:
> On 01/10/2017 08:32 AM, Juergen Gross wrote:
>> The default for the number of tx/rx queues of one interface is the
>> number of vcpus of the system today. As each queue pair reserves 512
>> grant pages this default consumes a ridiculous number of grants f
>>> On 14.12.16 at 05:07, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -169,6 +169,23 @@ struct feat_ops {
> */
> int (*compare_val)(const uint64_t val[], const struct feat_node *feat,
> unsigned int cos, bool *found);
> +/*
> + * ex
>>> On 14.12.16 at 05:07, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -186,6 +186,9 @@ struct feat_ops {
> unsigned int (*exceeds_cos_max)(const uint64_t val[],
> const struct feat_node *feat,
> un
On 1/10/17 2:38 AM, Jan Beulich wrote:
On 10.01.17 at 02:21, wrote:
>> On 12/5/16 4:25 PM, Daniel Kiper wrote:
>>> +/* Flags set in the 'flags' member of the multiboot header. */
>>> +#define MULTIBOOT2_TAG_TYPE_END0
>>> +#define MULTIBOOT2_TAG_TYPE_CMDLINE
On 10/01/17 15:02, Razvan Cojocaru wrote:
> On 01/10/2017 04:13 PM, Andrew Cooper wrote:
>> On 10/01/17 09:06, Razvan Cojocaru wrote:
>>> On 01/09/2017 02:54 PM, Andrew Cooper wrote:
On 09/01/17 11:36, Razvan Cojocaru wrote:
> Hello,
>
> We've come across a weird phenomenon: an Ubu
>>> What I meant was taking out this call:
>>>
>>> /* Remove the ring_pfn from the guest's physmap */
>>> rc1 = xc_domain_decrease_reservation_exact(xch, domain_id, 1, 0,
>>> &ring_pfn);
>>> if ( rc1 != 0 )
>>> PERROR("Failed to remove ring page from guest physmap");
>>>
>>> To
On 12/22/2016 03:41 PM, Dr. Greg Wettstein wrote:
> Functionality of the xen-tpmfront driver was lost secondary to
> the introduction of xenbus multi-page support in the following
> commit:
>
> ccc9d90a9a8b5c4ad7e9708ec41f75ff9e98d61d
>
> xenbus_client: Extend interface to support multi-page ring
>
On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
wrote:
> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
>> > On Mon, Jan 9, 2017 at 9:59 AM, Boris Ostrovsky
>> > wrote:
>> > > On 01/06/2017 08:06 PM, Konrad Rzeszutek Wilk wrot
On Wed, Jan 04, 2017 at 08:49:15PM +0100, Laszlo Ersek wrote:
> > diff --git a/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
> > b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
> > new file mode 100644
> > index 000..b5a4cf8
> > --- /dev/null
> > +++ b/OvmfPkg/XenResetVector/Ia32/PageTables64.as
Today xenstored tries to open an existing tdb file when started. As
this is known to be problematic the start script of xenstored is
deleting any old tdb file.
This can be made easier and less error prone by letting xenstored use
a new file.
Juergen Gross (2):
tools/xenstore: start with empty d
As xenstored now is always starting with an empty tdb data base there
is no need any longer to remove the file before starting xenstored.
A rerun of autogen.sh is required.
Signed-off-by: Juergen Gross
---
tools/hotplug/Linux/launch-xenstore.in | 1 -
1 file changed, 1 deletion(-)
diff --git a
Today xenstored tries to open a tdb data base file on disk when it is
started. As this is problematic in most cases the scripts used to start
xenstored ensure xenstored won't find such a file in order to start
with an empty xenstore.
A tdb data base file can't be used to restore all Xenstore state
flight 68350 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68350/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like
68308
test-armhf-
On Thu, Jan 05, 2017 at 10:59:24AM +0100, Laszlo Ersek wrote:
> On 12/08/16 16:33, Anthony PERARD wrote:
> > A copy of OvmfPkg/PlatformPei without some of QEMU specific
> > initialization, Xen does not support QemuFwCfg.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-of
On 1/10/17 21:26, Andrew Cooper wrote:
On 10/01/17 14:15, Andrew Cooper wrote:
On 10/01/17 14:03, Suravee Suthikulpanit wrote:
The order of destroy function calls in hvm_vcpu_destroy() should be
the reverse of init calls in hvm_vcpu_initialise().
Signed-off-by: Suravee Suthikulpanit
Reviewe
On Tue, Jan 10, 2017 at 8:35 AM, Razvan Cojocaru
wrote:
> >>> What I meant was taking out this call:
> >>>
> >>> /* Remove the ring_pfn from the guest's physmap */
> >>> rc1 = xc_domain_decrease_reservation_exact(xch, domain_id, 1, 0,
> >>> &ring_pfn);
> >>> if ( rc1 != 0 )
> >>>
On Thu, Jan 05, 2017 at 11:30:32AM +0100, Laszlo Ersek wrote:
> On 12/08/16 16:33, Anthony PERARD wrote:
> > - learn about memory size from the E820
> > - ignore error if host bridge devid is 0x, PVH does not have PCI and
> > reading from unexisting device return -1.
> >
> > Contributed-unde
flight 104098 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104098/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104086
test-armhf-armhf-libvirt
On 01/10/2017 06:29 PM, Tamas K Lengyel wrote:
>
>
> On Tue, Jan 10, 2017 at 8:35 AM, Razvan Cojocaru
> mailto:rcojoc...@bitdefender.com>> wrote:
>
> >>> What I meant was taking out this call:
> >>>
> >>> /* Remove the ring_pfn from the guest's physmap */
> >>> rc1 = xc_d
>>> +static int process_msg(void)
>>> +{
>>> + static struct xs_thread_state_read state;
>>> + struct xb_req_data *req;
>>> + int err;
>>> + unsigned int len;
>>> +
>>> + if (!state.in_msg) {
>>> + state.in_msg = true;
>>> + state.in_hdr = true;
>>> + state.
>> /*
>> * xs_response_mutex is locked as long as we are processing one
>> * message. state.in_msg will be true as long as we are holding the
>> * lock in process_msg().
>
> Then in_msg is the same as mutex_is_locked(&xs_response_mutex). And if
> so, do we really need it?
Nevermind this. The
On Tue, Jan 10, 2017 at 9:34 AM, Razvan Cojocaru
wrote:
> On 01/10/2017 06:29 PM, Tamas K Lengyel wrote:
> >
> >
> > On Tue, Jan 10, 2017 at 8:35 AM, Razvan Cojocaru
> > mailto:rcojoc...@bitdefender.com>> wrote:
> >
> > >>> What I meant was taking out this call:
> > >>>
> > >>> /*
On 10/01/17 17:36, Boris Ostrovsky wrote:
>
+static int process_msg(void)
+{
+ static struct xs_thread_state_read state;
+ struct xb_req_data *req;
+ int err;
+ unsigned int len;
+
+ if (!state.in_msg) {
+ state.in_msg = true;
+
From: Stefano Stabellini
This function creates userspace mapping for the DMA-coherent memory.
Signed-off-by: Stefano Stabellini
Signed-off-by: Oleksandr Dmytryshyn
Signed-off-by: Andrii Anisov
---
arch/arm/xen/mm.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
arch/arm/xen/mm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 050cf34..4061dd0 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -176,6 +176,16 @@ static int xen_swiotlb
From: Andrii Anisov
Some drivers need additional dma ops to be provided by xen swiotlb. Because
common operations implementation came from x86 world and does not suite ARM
needs.
dma_mmap patch is a port of an antique and lost patch discussed here:
http://marc.info/?l=xen-devel&m=139695901430667
On 01/10/17 17:18, Anthony PERARD wrote:
> On Thu, Jan 05, 2017 at 11:30:32AM +0100, Laszlo Ersek wrote:
>> On 12/08/16 16:33, Anthony PERARD wrote:
>>> - learn about memory size from the E820
>>> - ignore error if host bridge devid is 0x, PVH does not have PCI and
>>> reading from unexisting
On 01/10/2017 06:40 PM, Tamas K Lengyel wrote:
> > (replying to all): I'm not in favor of this patch mainly because it is
> > not stealthy. A malicious kernel could easily track what events are
> > being sent on the ring. With DRAKVUF I could work around this using
> > altp2m pfn-re
On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman wrote:
> On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
> wrote:
>> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
>>> > On Mon, Jan 9, 2017 at 9:59 AM, Boris Ostrovsky
>>> >
On Tue, Jan 10, 2017 at 06:44:25PM +0200, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Some drivers need additional dma ops to be provided by xen swiotlb. Because
> common operations implementation came from x86 world and does not suite ARM
> needs.
>
> dma_mmap patch is a port of an antique a
On Tue, Jan 10, 2017 at 05:54:49PM +0100, Laszlo Ersek wrote:
> On 01/10/17 17:18, Anthony PERARD wrote:
> > On Thu, Jan 05, 2017 at 11:30:32AM +0100, Laszlo Ersek wrote:
> >> On 12/08/16 16:33, Anthony PERARD wrote:
> >>> diff --git a/OvmfPkg/XenPlatformPei/Platform.c
> >>> b/OvmfPkg/XenPlatformP
On Tue, 10 Jan 2017, Dan Streetman wrote:
> On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman wrote:
> > On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
> > wrote:
> >> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
> >>> On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
> >>> > O
> diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c
> b/drivers/xen/xenbus/xenbus_dev_frontend.c
> index e4b9847..4d343ee 100644
> --- a/drivers/xen/xenbus/xenbus_dev_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
>
LGTM.
-boris
__
On Thu, Dec 08, 2016 at 03:33:39PM +, Anthony PERARD wrote:
> This "device" use XenIoMmioLib to reserve some space to be use by grant
> tables. It's use 0xfc00, which might not be a good choice...
Perhaps parse the E820 and find an E820_RSV region and use that?
And obviously don't use the
1 - 100 of 145 matches
Mail list logo
