Hi,
On 25/03/2020 16:34, Tamas K Lengyel wrote:
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 9f51370327..1ed7d13084 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -509,6 +509,12 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m,
unsigned long gfn_l,
On Wed, Mar 25, 2020 at 11:00:05AM -0600, Tamas K Lengyel wrote:
> On Wed, Mar 25, 2020 at 10:52 AM Julien Grall wrote:
> >
> >
> >
> > On 25/03/2020 16:47, Tamas K Lengyel wrote:
> > > On Wed, Mar 25, 2020 at 10:42 AM Julien Grall wrote:
> > >>
> > >> Hi,
> > >>
> > >> On 25/03/2020 16:34,
On Wed, Mar 25, 2020 at 11:16 AM Roger Pau Monné wrote:
>
> On Wed, Mar 25, 2020 at 11:00:05AM -0600, Tamas K Lengyel wrote:
> > On Wed, Mar 25, 2020 at 10:52 AM Julien Grall wrote:
> > >
> > >
> > >
> > > On 25/03/2020 16:47, Tamas K Lengyel wrote:
> > > > On Wed, Mar 25, 2020 at 10:42 AM
On Wed, Mar 25, 2020 at 04:42:07PM +, Julien Grall wrote:
> Hi,
>
> On 25/03/2020 16:34, Tamas K Lengyel wrote:
> > > > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> > > > index 9f51370327..1ed7d13084 100644
> > > > --- a/xen/arch/x86/mm/p2m.c
> > > > +++
On Wed, Mar 25, 2020 at 10:42 AM Julien Grall wrote:
>
> Hi,
>
> On 25/03/2020 16:34, Tamas K Lengyel wrote:
> >>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> >>> index 9f51370327..1ed7d13084 100644
> >>> --- a/xen/arch/x86/mm/p2m.c
> >>> +++ b/xen/arch/x86/mm/p2m.c
> >>> @@
Hi Jan,
On 25/03/2020 15:27, Jan Beulich wrote:
On 22.03.2020 17:14, jul...@xen.org wrote:
@@ -785,21 +781,21 @@ bool is_iomem_page(mfn_t mfn)
return (page_get_owner(page) == dom_io);
}
-static int update_xen_mappings(unsigned long mfn, unsigned int cacheattr)
+static int
flight 149001 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149001/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On 25/03/2020 16:47, Tamas K Lengyel wrote:
On Wed, Mar 25, 2020 at 10:42 AM Julien Grall wrote:
Hi,
On 25/03/2020 16:34, Tamas K Lengyel wrote:
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 9f51370327..1ed7d13084 100644
--- a/xen/arch/x86/mm/p2m.c
+++
Hi Jan,
On 25/03/2020 15:00, Jan Beulich wrote:
On 22.03.2020 17:14, jul...@xen.org wrote:
From: Julien Grall
It is getting incredibly difficult to use typesafe GFN/MFN/PFN in the
headers because of circular dependency. For instance, asm-x86/page.h
cannot include xen/mm.h.
In order to
On Wed, Mar 25, 2020 at 10:52 AM Julien Grall wrote:
>
>
>
> On 25/03/2020 16:47, Tamas K Lengyel wrote:
> > On Wed, Mar 25, 2020 at 10:42 AM Julien Grall wrote:
> >>
> >> Hi,
> >>
> >> On 25/03/2020 16:34, Tamas K Lengyel wrote:
> > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
On 24/03/2020 12:30, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On Wed, Mar 25, 2020 at 9:47 AM Roger Pau Monné wrote:
>
> Sorry it has taken me a while to get to this.
>
> On Mon, Mar 23, 2020 at 10:04:35AM -0700, Tamas K Lengyel wrote:
> > VM forking is the process of creating a domain with an empty memory space
> > and a
> > parent domain specified from
On 24/03/2020 12:33, Jan Beulich wrote:
> With the exception of HAVE_AS_QUOTED_SYM, populate the results into a
> generated header instead of (at least once per [sub]directory) into
> CFLAGS. This results in proper rebuilds (via make dependencies) in case
> the compiler used changes between
On 24/03/2020 12:29, Jan Beulich wrote:
> Note that SDM revision 070 doesn't specify exception behavior for
> ModRM.mod == 0b11; assuming #UD here.
Didn't I confirm this behaviour for you last time around?
> @@ -10075,6 +10079,14 @@ x86_emulate(
> : "0"
flight 148980 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148980/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 16 guest-localmigrate fail REGR. vs. 148925
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-amd
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
> From: Roger Pau Monné
> Sent: Tuesday, March 24, 2020 8:19 PM
>
> On Tue, Mar 24, 2020 at 11:33:00AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monné
> > > Sent: Tuesday, March 24, 2020 7:23 PM
> > >
> > > On Tue, Mar 24, 2020 at 10:11:15AM +, Tian, Kevin wrote:
> > > > > From: Roger
> From: Roger Pau Monne
> Sent: Wednesday, March 25, 2020 6:19 PM
>
> Check whether there's a valid interrupt in VM_EXIT_INTR_INFO in order
> to decide whether to update SVI in nvmx_update_apicv. If Ack on exit
> is not being used VM_EXIT_INTR_INFO won't have a valid interrupt and
> hence SVI
flight 148987 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148987/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs.
> From: Roger Pau Monne
> Sent: Wednesday, March 25, 2020 6:19 PM
>
> Force an update of the EOI exit bitmap in nvmx_update_apicv, because
> the one performed in vmx_intr_assist might not be reached if the
> interrupt is intercepted by nvmx_intr_intercept returning true.
>
> Extract the code to
flight 148995 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148995/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
148666
Tests which
> From: Roger Pau Monne
> Sent: Wednesday, March 25, 2020 6:19 PM
>
> Updating SVI is required when an interrupt has been injected using the
> Ack on exit VMEXIT feature, so that the in service interrupt in the
> GUEST_INTR_STATUS matches the vector that is signaled in
> VM_EXIT_INTR_INFO.
>
>
On 25.03.2020 11:55, Juergen Gross wrote:
> Today rcu_barrier() is calling stop_machine_run() to synchronize all
> physical cpus in order to ensure all pending rcu calls have finished
> when returning.
>
> As stop_machine_run() is using tasklets this requires scheduling of
> idle vcpus on all
On 23.03.2020 11:17, Andrew Cooper wrote:
> Every caller actually passes a struct microcode_header_intel. Implement the
> helpers with proper types, and leave a comment explaining the Pentium Pro/II
> behaviour with empty {data,total}size fields.
>
> No functional change.
>
> Signed-off-by:
On 22.03.2020 17:14, jul...@xen.org wrote:
> From: Julien Grall
>
> No functional changes intended.
>
> Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
On Mon, Mar 23, 2020 at 10:04:36AM -0700, Tamas K Lengyel wrote:
> Implement hypercall that allows a fork to shed all memory that got allocated
> for it during its execution and re-load its vCPU context from the parent VM.
> This allows the forked VM to reset into the same state the parent VM is
> > +static int bring_up_vcpus(struct domain *cd, struct domain *d)
> > +{
> > +unsigned int i;
> > +int ret = -EINVAL;
>
> Nit: you can get rid of ret...
>
> > +
> > +if ( d->max_vcpus != cd->max_vcpus ||
> > +(ret = cpupool_move_domain(cd, d->cpupool)) )
> > +return
On 23.03.2020 11:17, Andrew Cooper wrote:
> Rewrite the size checks in a way which which doesn't depend on Xen being
> compiled as 64bit.
One too many "which"?
> Introduce a check missing from the old code, that total_size is a multiple of
> 1024 bytes,
Where is this documented? The rather
On 23.03.2020 11:17, Andrew Cooper wrote:
> microcode_sanity_check()'s callers actually call it with a mixture of
> microcode_intel and microcode_header_intel pointers, which is fragile.
>
> Rework it to take struct microcode_intel *, which in turn requires
> microcode_update_match()'s type to be
On 23.03.2020 11:17, Andrew Cooper wrote:
> Implement a new get_ext_sigtable() helper to abstract the logic for
> identifying whether an extended signature table exists. As part of this,
> rename microcode_intel.bits to data and change its type so it can be usefully
> used in combination with the
On 24/03/2020 16:27, Jan Beulich wrote:
> Intel CPUs ignore operand size overrides here, while AMD ones don't.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 24/03/2020 16:27, Jan Beulich wrote:
> Intel CPUs ignore operand size overrides here, while AMD ones don't.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 22.03.2020 17:14, jul...@xen.org wrote:
> From: Julien Grall
>
> Introduce handy helpers to generate/convert the CR3 from/to a MFN/GFN.
>
> Note that we are using cr3_pa() rather than xen_cr3_to_pfn() because the
> latter does not ignore the top 12-bits.
I'm afraid this remark of yours
Hi Juergen,
On 25/03/2020 10:55, Juergen Gross wrote:
When using atomic variables for synchronization barriers are needed
to ensure proper data serialization. Introduce smp_mb__before_atomic()
and smp_mb__after_atomic() as in the Linux kernel for that purpose.
Use the same definitions as in
On 09.03.20 12:48, Julien Grall wrote:
Hi Juergen,
On 26/02/2020 12:46, Juergen Gross wrote:
On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.
In the beginning there should
On Wed, Mar 25, 2020 at 9:47 AM Roger Pau Monné wrote:
>
> Sorry it has taken me a while to get to this.
Thanks for the review, I'm addressing all the items you noticed in the
next revision.
Tamas
On 22.03.2020 17:14, jul...@xen.org wrote:
> From: Julien Grall
>
> It is getting incredibly difficult to use typesafe GFN/MFN/PFN in the
> headers because of circular dependency. For instance, asm-x86/page.h
> cannot include xen/mm.h.
>
> In order to convert more code to use typesafe, the
On 2020/3/24 19:55, Jan Beulich wrote:
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -316,6 +316,17 @@ typedef union
uint64_t raw;
} intinfo_t;
+typedef union
+{
+struct
+{
Nit: The brace should be on the same line as "struct"; can be
On 25.03.2020 11:55, Juergen Gross wrote:
> When using atomic variables for synchronization barriers are needed
> to ensure proper data serialization. Introduce smp_mb__before_atomic()
> and smp_mb__after_atomic() as in the Linux kernel for that purpose.
>
> Use the same definitions as in the
On 25/03/2020 14:16, Jan Beulich wrote:
> On 23.03.2020 11:17, Andrew Cooper wrote:
>> Currently, we allocate an 8 byte struct microcode_patch to point at a
>> separately allocated struct microcode_intel. This is wasteful.
> As indicated elsewhere I'm very much in favor of this, but I think it
>
On 22.03.2020 17:14, jul...@xen.org wrote:
> @@ -785,21 +781,21 @@ bool is_iomem_page(mfn_t mfn)
> return (page_get_owner(page) == dom_io);
> }
>
> -static int update_xen_mappings(unsigned long mfn, unsigned int cacheattr)
> +static int update_xen_mappings(mfn_t mfn, unsigned int
On Wed, Mar 25, 2020 at 9:52 AM Roger Pau Monné wrote:
>
> On Mon, Mar 23, 2020 at 10:04:36AM -0700, Tamas K Lengyel wrote:
> > Implement hypercall that allows a fork to shed all memory that got allocated
> > for it during its execution and re-load its vCPU context from the parent VM.
> > This
On 25/03/2020 15:22, Pu Wen wrote:
> On 2020/3/24 20:28, Andrew Cooper wrote:
>> Hmm - this field doesn't appear to be part of AVIC, which makes me
>> wonder what we're doing without it.
>>
>> It appears to be a shadow copy of EFLAGS.IF which is only written on
>> vmexit, and never consumed, but
On 2020/3/25 18:30, Roger Pau Monné wrote:
On Tue, Mar 24, 2020 at 06:37:26PM +0800, Pu Wen wrote:
diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h
b/xen/include/asm-x86/hvm/svm/vmcb.h
index b9e389d481..d8a3285752 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++
On 24/03/2020 16:26, Jan Beulich wrote:
> @@ -1995,7 +2007,7 @@ protmode_load_seg(
> case x86_seg_tr:
> goto raise_exn;
> }
> -if ( !(cp->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) ||
> +if ( !_amd_like(cp) ||
> !ops->read_segment
On 23.03.2020 11:17, Andrew Cooper wrote:
> static struct microcode_patch *cpu_request_microcode(const void *buf,
> size_t size)
> {
> -long offset = 0;
> int error = 0;
> -struct microcode_intel *mc, *saved = NULL;
> +const
On 24/03/2020 16:28, Jan Beulich wrote:
> Intel CPUs permit both insns there while AMD ones don't.
>
> While at it also
> - drop the ring 0 check from SYSENTER handling - neither Intel's nor
> AMD's insn pages have any indication of #GP(0) getting raised when
> executed from ring 0, and trying
Sorry it has taken me a while to get to this.
On Mon, Mar 23, 2020 at 10:04:35AM -0700, Tamas K Lengyel wrote:
> VM forking is the process of creating a domain with an empty memory space and
> a
> parent domain specified from which to populate the memory when necessary. For
> the new domain to
On 2020/3/24 20:28, Andrew Cooper wrote:
> Hmm - this field doesn't appear to be part of AVIC, which makes me
> wonder what we're doing without it.
>
> It appears to be a shadow copy of EFLAGS.IF which is only written on
> vmexit, and never consumed, but this is based on Appendix B which is the
>
On 25/03/2020 15:23, Pu Wen wrote:
> On 2020/3/25 18:30, Roger Pau Monné wrote:
>> On Tue, Mar 24, 2020 at 06:37:26PM +0800, Pu Wen wrote:
>>> diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h
>>> b/xen/include/asm-x86/hvm/svm/vmcb.h
>>> index b9e389d481..d8a3285752 100644
>>> ---
Hi Juergen,
On 25/03/2020 10:55, Juergen Gross wrote:
Today rcu_barrier() is calling stop_machine_run() to synchronize all
physical cpus in order to ensure all pending rcu calls have finished
when returning.
As stop_machine_run() is using tasklets this requires scheduling of
idle vcpus on all
On 24/03/2020 16:26, Jan Beulich wrote:
> Intel CPUs ignore operand size overrides here, while AMD ones don't.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 23.03.2020 11:17, Andrew Cooper wrote:
> Currently, we allocate an 8 byte struct microcode_patch to point at a
> separately allocated struct microcode_intel. This is wasteful.
As indicated elsewhere I'm very much in favor of this, but I think it
wants doing in one of the earlier series, and
Hello,
Are the following errors (and more similar ones):
CC xenctrl_stubs.o
In file included from /usr/lib64/ocaml/caml/alloc.h:24,
from xenctrl_stubs.c:22:
xenctrl_stubs.c: In function 'stub_xc_vcpu_context_get':
/usr/lib64/ocaml/caml/mlvalues.h:265:24: error: passing
On 24/03/2020 16:28, Jan Beulich wrote:
> AMD CPUs permit the insn everywhere (even outside of protected mode),
> while Intel ones restrict it to 64-bit mode. While at it also add the
> so far missing CPUID bit check.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
flight 149009 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149009/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 0537d246f8db3ac0a1df2ce653b07e85cd887962
baseline version:
xen
On Mon, Mar 23, 2020 at 04:43:18PM +, Peter Maydell wrote:
> The function usbback_packet_complete() currently takes a USBPacket*,
> which must be a pointer to the packet field within a struct
> usbback_req; the function uses container_of() to get the struct
> usbback_req* given the USBPacket*.
On 24.03.2020 19:39, Julien Grall wrote:
> On 24/03/2020 16:13, Jan Beulich wrote:
>> On 24.03.2020 16:21, Hongyan Xia wrote:
>>> From: Hongyan Xia
>>> In contrast,
>>> after dropping that commit, parallel domain destructions will just fail
>>> to take the domctl lock, creating a hypercall
flight 148964 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148964/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
146121
Tests which
On 24/03/2020 16:29, Jan Beulich wrote:
> This is to augment SYSCALL, which has been supported for quite some
> time.
>
> Signed-off-by: Jan Beulich
I've compared this to the in-progress version I have in my XSA-204
follow-on series. I'm afraid the behaviour has far more vendor specific
quirks
On 25.03.2020 11:00, Andrew Cooper wrote:
> On 24/03/2020 16:29, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -5975,6 +5975,60 @@ x86_emulate(
>> goto done;
>> break;
>>
>> +case
This reverts commit f96e1469ad06b61796c60193daaeb9f8a96d7458.
The commit is wrong, as the whole point of nvmx_update_apicv is to
update the guest interrupt status field when the Ack on exit VMEXIT
control feature is enabled.
Signed-off-by: Roger Pau Monné
Reviewed-by: Kevin Tian
---
Force an update of the EOI exit bitmap in nvmx_update_apicv, because
the one performed in vmx_intr_assist might not be reached if the
interrupt is intercepted by nvmx_intr_intercept returning true.
Extract the code to update the exit bitmap from vmx_intr_assist into a
helper and use it in
Updating SVI is required when an interrupt has been injected using the
Ack on exit VMEXIT feature, so that the in service interrupt in the
GUEST_INTR_STATUS matches the vector that is signaled in
VM_EXIT_INTR_INFO.
Updating RVI however is not tied to the Ack on exit feature, as it
signals the
Hello,
osstest identified a regression caused by my earlier attempt to fix
interrupt injection when using nested VMX. This series aims to fix the
regression, and should unblock several osstest branches.
The following report is from osstest with this series applied:
Check whether there's a valid interrupt in VM_EXIT_INTR_INFO in order
to decide whether to update SVI in nvmx_update_apicv. If Ack on exit
is not being used VM_EXIT_INTR_INFO won't have a valid interrupt and
hence SVI shouldn't be updated to signal the interrupt is currently in
service because it
Xen's RCU implementation relies on no softirq handling taking place
while being in a RCU critical section. Add ASSERT()s in debug builds
in order to catch any violations.
For that purpose modify rcu_read_[un]lock() to use a dedicated percpu
counter additional to preempt_[en|dis]able() as this
Today rcu_barrier() is calling stop_machine_run() to synchronize all
physical cpus in order to ensure all pending rcu calls have finished
when returning.
As stop_machine_run() is using tasklets this requires scheduling of
idle vcpus on all cpus imposing the need to call rcu_barrier() on idle
cpus
Some keyhandlers are calling process_pending_softirqs() while holding
a rcu_read_lock(). This is wrong, as process_pending_softirqs() might
activate rcu calls which should not happen inside a rcu_read_lock().
For that purpose modify process_pending_softirqs() to not allow rcu
callback processing
Add a lock specific counter to rcu read locks in debug builds. This
allows to test for matching lock/unlock calls.
This will help to avoid cases like the one fixed by commit
98ed1f43cc2c89 where different rcu read locks were referenced in the
lock and unlock calls.
Signed-off-by: Juergen Gross
Today the RCU handling in Xen is affecting scheduling in several ways.
It is raising sched softirqs without any real need and it requires
tasklets for rcu_barrier(), which interacts badly with core scheduling.
This small series repairs those issues.
Additionally some ASSERT()s are added for
When using atomic variables for synchronization barriers are needed
to ensure proper data serialization. Introduce smp_mb__before_atomic()
and smp_mb__after_atomic() as in the Linux kernel for that purpose.
Use the same definitions as in the Linux kernel.
Suggested-by: Jan Beulich
> -Original Message-
> From: Jan Beulich
> Sent: 24 March 2020 12:43
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant ;
> Wei Liu ;
> Roger Pau Monne
> Subject: Re: [PATCH v5 00/10] x86emul: further work
>
> Paul,On 24.03.2020 13:26, Jan Beulich wrote:
> > Some
Adding the PCI and IOMMU maintainers.
On Mon, Mar 23, 2020 at 01:55:01PM -0700, Roman Shaposhnik wrote:
> Hi!
>
> I was going through how Xen support PCIe IOMMU ACS and
> all I could find is this:
>
> https://github.com/xen-project/xen/blob/master/xen/drivers/passthrough/pci.c#L608
> which
This email only tracks big items for xen.git tree. Please reply for items
you would like to see in 4.14 so that people have an idea what
is going on and prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
We now adopt a
On Tue, Mar 24, 2020 at 06:37:26PM +0800, Pu Wen wrote:
> diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h
> b/xen/include/asm-x86/hvm/svm/vmcb.h
> index b9e389d481..d8a3285752 100644
> --- a/xen/include/asm-x86/hvm/svm/vmcb.h
> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h
> @@ -316,6 +316,17 @@
On Tue, Mar 24, 2020 at 03:45:30AM +0100, Marek Marczykowski-Górecki wrote:
> On Mon, Mar 23, 2020 at 04:35:12PM +0100, Roger Pau Monné wrote:
> > On Mon, Jan 06, 2020 at 05:03:40PM +0100, Marek Marczykowski-Górecki wrote:
> > > > * There needs to be a way to deal with a broken/unresponsive
Hello,
I'm a Ph.D. candidate in UC (Portugal) working with Xen's vulnerability
discovery process, right now focusing on modeling, and I'd like to
understand the process before the disclosure (by XSA or CVE/NVD).
It would be nice to have a more precise date that traces a vulnerability
(XSA) to
On 25/03/2020 10:19, Jan Beulich wrote:
> On 25.03.2020 11:00, Andrew Cooper wrote:
>> On 24/03/2020 16:29, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -5975,6 +5975,60 @@ x86_emulate(
>>> goto done;
>>>
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 24 March 2020 12:34
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant
> ; Wei Liu
> ; Roger Pau Monne
> Subject: [Xen-devel] [PATCH v5 05/10] x86emul: support MOVDIR64B insn
>
> Introduce a
On 24/03/2020 12:26, Jan Beulich wrote:
> Some of the later patches are still at least partly RFC, for
> varying reasons (see there). I'd appreciate though if at least
> some of the earlier ones could go in rather sooner than later.
>
> Patch 1 functionally (for the test harness) depends on
>
On 25.03.2020 12:41, Andrew Cooper wrote:
> On 24/03/2020 12:26, Jan Beulich wrote:
>> Some of the later patches are still at least partly RFC, for
>> varying reasons (see there). I'd appreciate though if at least
>> some of the earlier ones could go in rather sooner than later.
>>
>> Patch 1
On 25.03.2020 12:19, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 24 March 2020 12:34
>> To: xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper ; Paul Durrant
>> ; Wei Liu
>> ; Roger Pau Monne
>> Subject: [Xen-devel] [PATCH v5
On 25.03.2020 11:00, Andrew Cooper wrote:
> On 24/03/2020 16:29, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -5975,6 +5975,60 @@ x86_emulate(
>> goto done;
>> break;
>>
>> +case
On 25/03/2020 11:55, Jan Beulich wrote:
> On 25.03.2020 11:00, Andrew Cooper wrote:
>> On 24/03/2020 16:29, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -5975,6 +5975,60 @@ x86_emulate(
>>> goto done;
>>>
85 matches
Mail list logo
