On 8/13/18 4:38 PM, Jan Beulich wrote:
On 13.08.18 at 15:19, wrote:
>> On 8/13/18 3:58 PM, Jan Beulich wrote:
>> On 13.08.18 at 14:51, wrote:
So first we've got that vmx_idtv_reinject() call writing to the VMCS,
then we emulate a CLI, then the failed vmentry. I can't tell if th
On 8/13/18 4:38 PM, Jan Beulich wrote:
On 13.08.18 at 15:19, wrote:
>> On 8/13/18 3:58 PM, Jan Beulich wrote:
>> On 13.08.18 at 14:51, wrote:
So first we've got that vmx_idtv_reinject() call writing to the VMCS,
then we emulate a CLI, then the failed vmentry. I can't tell if th
On 8/13/18 4:45 PM, Razvan Cojocaru wrote:
> On 8/13/18 4:38 PM, Jan Beulich wrote:
>>>>> On 13.08.18 at 15:19, wrote:
>>> On 8/13/18 3:58 PM, Jan Beulich wrote:
>>>>>>> On 13.08.18 at 14:51, wrote:
>>>>> So first we've got that
On 8/17/18 6:12 PM, Wei Liu wrote:
> Going through the code, nested EPT, EPT, and ALTP2M depend on HVM code. Put
> these components under CONFIG_HVM. This further requires putting one
> of the vm event under CONFIG_HVM.
>
> Also make hap_enabled evaluate to false when !CONFIG_HVM. This in turn
> r
> int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
> struct p2m_domain *ap2m, p2m_access_t a,
>
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 8/17/18 6:12 PM, Wei Liu wrote:
> Ideally the HVM specific part of VM event should be moved into hvm/ at
> some point, but this will do for now.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/vm_event.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xen/arch/x86/vm_event.c b/xen
On 8/21/18 1:45 PM, Wei Liu wrote:
> On Sun, Aug 19, 2018 at 07:41:11PM +0300, Razvan Cojocaru wrote:
>> On 8/17/18 6:12 PM, Wei Liu wrote:
>>> Ideally the HVM specific part of VM event should be moved into hvm/ at
>>> some point, but this will do for now.
>
MD IOMMU initialization code has
> been replaced with a test of iommu_dom0_strict since this more
> accurately reflects the meaning of the test and brings it into
> line with a similar test in the Intel VT-d code.
>
> Signed-off-by: Paul Durrant
F
On 8/24/18 8:07 AM, sepanta s wrote:
> I debugged the kernel codes and found out the root cause.
> The sharing is not done for some pages causing error -E2BIG which is due
> to reference count being more than one. This prevents hypervor to
> nominate the page. As much as I know about this issue, th
On 8/24/18 8:49 PM, Andrew Cooper wrote:
> On 24/08/18 15:11, Alexandru Isaila wrote:
>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>> index 03a864156..b01194d 100644
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -212,7 +212,20 @@ bo
On 8/26/18 3:19 PM, Wei Liu wrote:
> There has been plan to make PV work, but it is not yet there. Provide
> stubs to make it build with !CONFIG_HVM.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/Makefile | 2 +-
> xen/include/asm-x86/monitor.h | 14 ++
> 2 files changed,
M. This in turn
> requires marking a variable in p2m_set_entry as __maybe_unused.
>
> Signed-off-by: Wei Liu
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 8/27/18 12:11 PM, Jan Beulich wrote:
On 24.08.18 at 20:47, wrote:
>> 619 /* EPT violation qualifications definitions */
>> 620 typedef union ept_qual {
>> 621 unsigned long raw;
>> 622 struct {
>> 623 bool read:1, write:1, fetch:1,
>> 624 eff_read:1, eff_write:1
On 8/27/18 3:12 PM, Jan Beulich wrote:
>>> For NPT, isn't there an error code bit telling you whether the
>>> request was a user or "system" one? If not, some cheating
>>> would be needed (derive from CPL, accepting that e.g.
>>> descriptor table accesses would get mis-attributed), but
>>> that's s
On 8/27/18 3:37 PM, Andrew Cooper wrote:
> On 27/08/18 13:12, Jan Beulich wrote:
For NPT, isn't there an error code bit telling you whether the
request was a user or "system" one? If not, some cheating
would be needed (derive from CPL, accepting that e.g.
descriptor table access
On 8/27/18 4:02 PM, Andrew Cooper wrote:
> On 27/08/18 13:53, Razvan Cojocaru wrote:
>> On 8/27/18 3:37 PM, Andrew Cooper wrote:
>>> On 27/08/18 13:12, Jan Beulich wrote:
>>>>>> For NPT, isn't there an error code bit telling you whether the
>>>&g
On 8/27/18 4:17 PM, Jan Beulich wrote:
On 27.08.18 at 15:02, wrote:
>> This should be architecturally correct as it is exclusively derived from
>> information provided by the VMExit, and won't cause dirty bits to be
>> written in cases where the hardware wouldn't have written them
>> (specula
On 8/27/18 6:18 PM, Jan Beulich wrote:
On 26.08.18 at 14:19, wrote:
>> There has been plan to make PV work, but it is not yet there. Provide
>> stubs to make it build with !CONFIG_HVM.
>>
>> Signed-off-by: Wei Liu
>> ---
>> xen/arch/x86/Makefile | 2 +-
>> xen/include/asm-x86/moni
On 8/28/18 11:13 AM, Jan Beulich wrote:
On 28.08.18 at 10:04, wrote:
>> On 27/08/18 15:08, Jan Beulich wrote:
>> On 27.08.18 at 15:47, wrote:
On 8/27/18 4:17 PM, Jan Beulich wrote:
On 27.08.18 at 15:02, wrote:
>> This should be architecturally correct as it is exclusiv
On 8/22/18 5:02 PM, Alexandru Isaila wrote:
> This is used to save data from a single instance.
>
> Signed-off-by: Alexandru Isaila
> Reviewed-by: Jan Beulich
>
> ---
> Changes since V14:
> - Move all free fields to the initializer
> - Add blank line to before the return
> - M
Andrew Cooper
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 8/28/18 8:39 PM, Andrew Cooper wrote:
> The trailing _vcpu suffix is redundant, but adds to code volume. Drop it.
>
> Reflow lines as appropriate, and switch to using the new XFREE/etc wrappers
> where applicable.
>
> No functional change.
>
> Signed-off-by: Andrew C
On 8/29/18 8:43 PM, Tamas K Lengyel wrote:
> On Wed, Aug 29, 2018 at 10:42 AM Wei Liu wrote:
>>
>> On Mon, Aug 27, 2018 at 09:18:29AM -0600, Jan Beulich wrote:
>> On 26.08.18 at 14:19, wrote:
There has been plan to make PV work, but it is not yet there. Provide
stubs to make it bui
Woods
> CC: Roger Pau Monné
> CC: Juergen Gross
> CC: Dario Faggioli
> CC: Paul Durrant
> CC: Razvan Cojocaru
> CC: Tamas K Lengyel
>
> It is unfortunate that this is one monolithic patch, but I can't find any
> reasonable way to split it up.
> ---
>
On 9/2/18 10:10 PM, Spencer Michaels wrote:
> I have found, however, that quite a few major debugging features ---
> chiefly,
> breakpoints and single-step mode --- do not appear to be supported for PV
> guests. Looking through the source of Xen itself seems to confirm this
> [1]. It
> looks like t
ve log message is also present.
>
> Update all callers to either merge with a previous printk(), or invent an
> informative log message. A few select callers are switched to the
> non-printing version, when they've already emitted a relevent state dump.
>
> Sig
umably not trigger the necessary faults after switching to
the new altp2m.
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/mm/p2m-ept.c | 53 +--
xen/arch/x86/mm/p2m.c | 49 +++
2 files changed, 87 inserti
On 9/3/18 4:27 PM, Jan Beulich wrote:
On 03.09.18 at 10:25, wrote:
>> When an new altp2m view is created very early on guest boot, the
>> display will freeze (although the guest will run normally). This
>> may also happen on resizing the display. The reason is the way
>> Xen currently (mis)ha
On 9/4/18 7:15 PM, Wei Liu wrote:
> There has been plan to make PV work, but it is not yet there. Provide
> stubs to make it build with !CONFIG_HVM.
>
> Signed-off-by: Wei Liu
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel
ose fields
> under CONFIG_HVM.
>
> Signed-off-by: Wei Liu
Signed-off-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 9/4/18 8:08 PM, Razvan Cojocaru wrote:
> On 9/4/18 7:15 PM, Wei Liu wrote:
>> Populate-on-demand is HVM only.
>>
>> Provide a bunch of stubs for common p2m code and guard one invocation
>> of guest_physmap_mark_populate_on_demand with is_hvm_domain.
>>
>>
is embedded in
> generic x86 p2m code.
>
> Also make hap_enabled evaluate to false when !CONFIG_HVM. Make sure it
> evaluate its parameter to avoid unused variable warnings in its users.
>
> Also sort items in Makefile while at it.
>
> Signed-off-by: Wei Liu
Acke
On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
> On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop wrote:
>>
>> In a classic HVI + Xen setup, the introspection engine would monitor
>> legacy guest page-tables by marking them read-only inside the EPT; this
>> way any modification explicitly made by the guest
On 9/5/18 9:56 AM, Jan Beulich wrote:
On 04.09.18 at 22:58, wrote:
>> On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
>>> On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop wrote:
In a classic HVI + Xen setup, the introspection engine would monitor
legacy guest page-tables by marking them
On 9/5/18 9:56 AM, Jan Beulich wrote:
On 04.09.18 at 22:58, wrote:
>> On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
>>> On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop wrote:
In a classic HVI + Xen setup, the introspection engine would monitor
legacy guest page-tables by marking them
On 9/5/18 7:28 PM, Tamas K Lengyel wrote:
> On Tue, Sep 4, 2018 at 2:58 PM Razvan Cojocaru
> wrote:
>>
>> On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
>>> On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop wrote:
>>>>
>>>> In a classic HVI + Xen setup,
On 9/5/18 9:40 PM, Tamas K Lengyel wrote:
>>> Sounds good, thanks!
>> May we take that as an Acked-by, or are there are other things you think
>> we should address?
> A Reviewed-by would be appropriate, I don't think the files touched in
> this patch fall under our umbrella.
You're right, I just s
the use sites do the conversion to gfn_t as suitable.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Paul Durrant
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 9/13/18 8:29 PM, Spencer Michaels wrote:
> I'm writing an application that can read/write guest memory, and as part
> of that I need to check whether the page being manipulated is
> readable/writable by the guest itself. Does Xen have an API that would
> allow me to read the flags of an arbitrar
On 9/18/18 9:20 PM, Andrew Cooper wrote:
> On 18/09/18 11:17, Jan Beulich wrote:
> On 18.09.18 at 11:47, wrote:
>>> On Thu, 2018-09-13 at 08:17 -0600, Jan Beulich wrote:
>>> On 12.09.18 at 11:47, wrote:
> The original version of the patch emulated the current instruction
> (which,
On 9/19/18 12:39 PM, Jan Beulich wrote:
On 19.09.18 at 11:19, wrote:
>> On Wed, 2018-09-19 at 03:01 -0600, Jan Beulich wrote:
>> On 19.09.18 at 10:21, wrote:
I want to restart the discussion on dropping the "if ( v-
> pause_flags &
VPF_down )" from hvm_save_cpu_ctxt()
On 9/19/18 3:13 PM, Jan Beulich wrote:
On 19.09.18 at 13:11, wrote:
>> The scenario is that we are trying to query the state of a VCPU (please
>> note: just query). That means that we're only interested in getting some
>> coherent VCPU state via the XEN_DOMCTL_gethvmcontext_partial domctl.
>>
On 9/19/18 3:15 PM, George Dunlap wrote:
> Hey Razvan, thanks for doing this, and sorry it's taken so long to respond.
No problem, thanks for the review!
>> We should discuss if just copying over
>> logdirty_ranges (which is a pointer) is sufficient, or if
>> this code requires more synchroni
> But actually the sequence I'm worried about is:
>
> 1. Misconfigure hostp2m
> 2. Create altp2m
> 3. Enable altp2m
> 4. Switch to altp2m 1
> 5. A would-be-fault in the hostp2m no longer occurs
>
> Please note the additional step 2. At this point, the hostp2m has been
> misconfigured, but the cre
On 9/19/18 4:08 PM, George Dunlap wrote:
> On 09/19/2018 02:01 PM, Razvan Cojocaru wrote:
>> On 9/19/18 3:15 PM, George Dunlap wrote:
>>> Hey Razvan, thanks for doing this, and sorry it's taken so long to respond.
>>
>> No problem, thanks for the review!
>&g
On 9/19/18 3:15 PM, George Dunlap wrote:
>> * has p2m_init_altp2m_ept() copy over max_mapped_pfn,
>> logdirty_ranges, global_logdirty, ept.ad and default_access
>> from the hostp2m (the latter more for completeness than for any
>> other reason).
> I think this is probably the right approach.
All we want to do is to be able to query the state of any VCPU in the
valid range of VCPUs assigned to the domain, online or not. We believe
being able to query them is reasonable, and the SDM states that they do
have a state (whatever it happens to be: the init state, after res
On 9/19/18 5:48 PM, Wei Liu wrote:
> On Mon, Sep 03, 2018 at 06:48:36PM +0300, Adrian Pop wrote:
>> Signed-off-by: Adrian Pop
>
> Acked-by: Wei Liu
>
> FAOD I'm expecting you to address Tamas' comment in patch 1 and resend.
Hello Wei,
That has already been addressed in V6, and the patch is al
On 9/6/18 1:27 AM, Tamas K Lengyel wrote:
> On Wed, Sep 5, 2018 at 12:45 PM Andrew Cooper
> wrote:
>>
>> On 05/09/18 19:40, Tamas K Lengyel wrote:
>>> On Wed, Sep 5, 2018 at 10:40 AM Razvan Cojocaru
>>> wrote:
>>>> On 9/5/18 7:28 PM, Tamas K Len
On 9/20/18 11:14 AM, Wei Liu wrote:
>>> Reviewed-by: Tamas K Lengyel
>> Are there any issues preventing this patch to go in? Possibly missing acks?
> I don't think so, unless an explicit ack for the deletion of that
> comment is required. In any case:
>
> Acked-by: Wei Liu
>
> I will commit thi
On 9/20/18 11:31 AM, Wei Liu wrote:
Reviewed-by: Tamas K Lengyel
>>> Are there any issues preventing this patch to go in? Possibly missing acks?
>> Well, afaics the patch has no x86 maintainer ack, nor - considering it's
>> an mm function sitting in the "wrong" file, at least one from the mm
On 9/20/18 2:34 PM, George Dunlap wrote:
> On 09/03/2018 04:48 PM, Adrian Pop wrote:
>> Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a
>> domain to change the value of the #VE suppress bit for a page.
>>
>> Add a libxc wrapper for invoking this hvmop.
>>
>> Signed-off-by: Adria
On 9/20/18 5:42 PM, George Dunlap wrote:
> I do have a question about your proposed use case. You're running
> this in 'mixed' mode, right, and using the altp2m to hide a secure bit
> of code from the operating system? What's to stop a rogue operating
> system that doesn't want to be introspected
On 9/20/18 2:34 PM, George Dunlap wrote:
>> +int p2m_set_suppress_ve(struct domain *d, gfn_t gfn, bool suppress_ve,
>> +unsigned int altp2m_idx)
> This should clearly be in p2m.c, and...
>
>> +{
>> +struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
>> +struct p2m_do
Hello,
While doing my best to make sure what I understand to be George's
proposed changes for the altp2m series I've tried to boot Xen staging on
an AMD host, but it crashes in an unrelated place (I've tested this by
stashing my changes and booting a "vanilla" staging):
(XEN) Dom0 has maximum 16
On 9/21/18 1:41 PM, Jan Beulich wrote:
>>>> On 21.09.18 at 12:15, wrote:
>> On Fri, Sep 21, 2018 at 12:45:18PM +0300, Razvan Cojocaru wrote:
>>> While doing my best to make sure what I understand to be George's
>>> proposed changes for the altp2m series
:
>>>>>>>> On 21.09.18 at 12:15, wrote:
>>>>>> On Fri, Sep 21, 2018 at 12:45:18PM +0300, Razvan Cojocaru wrote:
>>>>>>> While doing my best to make sure what I understand to be George's
>>>>>>> proposed changes for
On 9/20/18 3:50 PM, George Dunlap wrote:
> On 09/03/2018 04:48 PM, Adrian Pop wrote:
>> Signed-off-by: Adrian Pop
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -550,6 +550,51 @@ out:
>> return rc;
>> }
>>
>> +int p2m_get_suppress_ve(struct domain *d, gfn_t gfn, bool *suppress_ve,
>> +
On 9/21/18 4:16 PM, Razvan Cojocaru wrote:
> On 9/20/18 3:50 PM, George Dunlap wrote:
>> On 09/03/2018 04:48 PM, Adrian Pop wrote:
>>> Signed-off-by: Adrian Pop
>>> +++ b/xen/arch/x86/mm/mem_access.c
>>> @@ -550,6 +550,51 @@ out:
>>> return
these functions to p2m.c (but waiting for
George's reply on the VMX #VE checks), so if you'd like - and feel
that's appropriate - I can also put that code under CONFIG_HVM in the
cleanup patch. Is that something you'd be interested in?
Otherwise, Acked-by: Razvan Cojocaru
On 9/21/18 7:03 PM, Wei Liu wrote:
> On Fri, Sep 21, 2018 at 06:57:39PM +0300, Razvan Cojocaru wrote:
>> On 9/21/18 6:54 PM, Wei Liu wrote:
>>> They are used by HVM code only.
>>>
>>> Signed-off-by: Wei Liu
>>> ---
>>> v5: new
>>> -
: Razvan Cojocaru
---
xen/arch/x86/mm/mem_access.c | 102 ---
xen/arch/x86/mm/p2m-ept.c| 21 +
xen/arch/x86/mm/p2m-pt.c | 3 +-
xen/arch/x86/mm/p2m.c| 93 +++
4 files changed, 116 insertions
On 9/23/18 7:33 PM, George Dunlap wrote:
> Sorry, looks like this may not have gone through.
> -G
> On Thu, Sep 20, 2018 at 5:08 PM George Dunlap
> wrote:
>>
>> On Thu, Sep 20, 2018 at 4:53 PM Razvan Cojocaru
>> wrote:
>>>
>>> On
On 9/24/18 6:25 PM, George Dunlap wrote:
> On 09/23/2018 06:04 PM, Razvan Cojocaru wrote:
>> Move p2m_{get/set}_suppress_ve() to p2m.c, replace incorrect
>> ASSERT() in p2m-pt.c (since a guest can run in shadow mode even on
>> a system with virt exceptions, which wou
code in
p2m_get_suppress_ve().
Signed-off-by: Razvan Cojocaru
---
Changes since V1:
- Did not add Tamas' ack because of the non-trivial V2 changes.
- Removed the checks for #VE support / #VE active from
ept_get_entry().
- Removed duplicate gfn_eq(vcpu_altp2m(current).veinfo_gfn,
INVALI
On 9/25/18 1:09 PM, George Dunlap wrote:
> On 09/25/2018 09:36 AM, Razvan Cojocaru wrote:
>> Move p2m_{get/set}_suppress_ve() to p2m.c, replace incorrect
>> ASSERT() in p2m-pt.c (since a guest can run in shadow mode even on
>> a system with virt exceptions, which wou
code in
p2m_get_suppress_ve().
Signed-off-by: Razvan Cojocaru
---
Changes since V2:
- Rebased on staging, double-checked the patch.
---
xen/arch/x86/mm/mem_access.c | 102 ---
xen/arch/x86/mm/p2m-ept.c| 11 +
xen/arch/x86/mm/p2m-pt.c | 3
On 9/19/18 6:29 PM, Tamas K Lengyel wrote:
> On Mon, Sep 3, 2018 at 9:47 AM Adrian Pop wrote:
>> diff --git a/xen/include/public/hvm/hvm_op.h
>> b/xen/include/public/hvm/hvm_op.h
>> index bbba99e5f5..bbb0aa984a 100644
>> --- a/xen/include/public/hvm/hvm_op.h
>> +++ b/xen/include/public/hvm/hvm_op
from xen_hvm_altp2m_set_mem_access.
Signed-off-by: Adrian Pop
Signed-off-by: Razvan Cojocaru
---
Changes since V4:
- Replaced the "if ( altp2m_idx ) return -EINVAL;" test in
p2m_get_mem_access() with "ASSERT(altp2m_idx == 0);" for ARM.
- Removed XEN_INTERFACE_VE
On 9/26/18 10:34 AM, Razvan Cojocaru wrote:
> Currently there is a subop for setting the memaccess of a page, but not
> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
> functionality.
>
> Both altp2m get/set mem access functions use the struct
> xen_hvm_altp2
On 9/26/18 2:39 PM, Razvan Cojocaru wrote:
> On 9/26/18 10:34 AM, Razvan Cojocaru wrote:
>> Currently there is a subop for setting the memaccess of a page, but not
>> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
>> functionality.
>>
>> Both al
On 9/26/18 4:20 PM, Jan Beulich wrote:
On 26.09.18 at 14:26, wrote:
>> To clarify the question, I'll of course do this:
>>
>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>> index 67b4a1d..2b5a621 100644
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/m
On 9/26/18 4:39 PM, Jan Beulich wrote:
On 26.09.18 at 15:27, wrote:
>> On 9/26/18 4:20 PM, Jan Beulich wrote:
>> On 26.09.18 at 14:26, wrote:
To clarify the question, I'll of course do this:
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
inde
from xen_hvm_altp2m_set_mem_access.
Signed-off-by: Adrian Pop
Signed-off-by: Razvan Cojocaru
---
Changes since V5:
- Fixed the build by conditionally-compiling the altp2m code
gated on CONFIG_HVM being #defined.
---
tools/libxc/include/xenctrl.h | 3 +++
tools/libxc/xc_altp2m.c
On 9/28/18 12:04 PM, Wei Liu wrote:
> On Wed, Sep 26, 2018 at 03:26:20PM +0300, Razvan Cojocaru wrote:
>> but is it OK that the hypervisor builds with a set of flags that
>> includes CONFIG_HVM and the firmware code with a set that doesn't?
>
> To answer this question
tp2ms will inherit the hostp2m's
ept.ad value. ept_set_ad_sync() is now also the code
responsible for locking updated p2ms.
Signed-off-by: Razvan Cojocaru
Suggested-by: George Dunlap
---
xen/arch/x86/mm/p2m-ept.c | 55 ---
xen/arch/x86/mm/p2m.c
On 9/28/18 2:55 PM, Razvan Cojocaru wrote:
> This patch is a pre-requisite for fixing the logdirty VGA issue
> (display freezes when switching to a new altp2m view early in a
> domain's lifetime), but sent separately for easier review.
> The new ept_set_ad_sync() function has bee
On 9/28/18 5:52 PM, Jan Beulich wrote:
On 28.09.18 at 13:55, wrote:
>> @@ -1218,34 +1219,67 @@ static void ept_tlb_flush(struct p2m_domain *p2m)
>> ept_sync_domain_mask(p2m, p2m->domain->dirty_cpumask);
>> }
>>
>> +static void ept_set_ad_sync(struct p2m_domain *p2m, int value)
>
> Ca
On 9/28/18 6:55 PM, Jan Beulich wrote:
On 28.09.18 at 17:25, wrote:
>> On 9/28/18 5:52 PM, Jan Beulich wrote:
>> On 28.09.18 at 13:55, wrote:
@@ -1218,34 +1219,67 @@ static void ept_tlb_flush(struct p2m_domain *p2m)
ept_sync_domain_mask(p2m, p2m->domain->dirty_cpumask);
>>
tp2ms will inherit the hostp2m's
ept.ad value. ept_set_ad_sync() is now also the code
responsible for locking updated p2ms.
Signed-off-by: Razvan Cojocaru
Suggested-by: George Dunlap
---
Changes since V1:
- Removed unnecessary p2m_lock() in p2m_init_altp2m_ept().
- Changed value's t
On 10/1/18 1:39 PM, Jan Beulich wrote:
On 01.10.18 at 11:58, wrote:
>> Changes since V1:
>> - Removed unnecessary p2m_lock() in p2m_init_altp2m_ept().
>
> This was a step in the right direction, but ...
>
>> static void ept_enable_pml(struct p2m_domain *p2m)
>> {
>> +struct domain
On 10/1/18 2:23 PM, George Dunlap wrote:
> On 10/01/2018 12:11 PM, Razvan Cojocaru wrote:
>>
>>
>> On 10/1/18 1:39 PM, Jan Beulich wrote:
>>>>>> On 01.10.18 at 11:58, wrote:
>>>> Changes since V1:
>>>> - Removed unnecessary p2m_
tp2ms will inherit the hostp2m's
ept.ad value. ept_set_ad_sync() is now also the code
responsible for locking updated p2ms.
Signed-off-by: Razvan Cojocaru
Suggested-by: George Dunlap
---
Changes since V2:
- Proper hostp2m locking in ept_{enable,disable}_pml().
- Added two asserts in ept_set_ad_s
On 10/2/18 7:29 PM, Сергей wrote:
> Hello Razvan.
>
> Have Your patch been accepted in Xen hypervisor?
>
> Searching through git I have found commit
> "61bdddb82151fbf51c58f6ebc1b4a687942c45a8" on "Thu Jun 28 10:54:01 2018
> +0300". Is that commit deals with the error?
No yet, we're working on
On 10/3/18 1:56 PM, Сергей wrote:
>> No yet, we're working on it.
> Could You point me to the branch with Your patches please? I Could not find
> it in https://xenbits.xen.org/gitweb/?p=xen.git
There's no public branch with my patches, I'm working locally. The
original patch has now split into tw
On 10/3/18 1:56 PM, Сергей wrote:
>> No yet, we're working on it.
> Could You point me to the branch with Your patches please? I Could not find
> it in https://xenbits.xen.org/gitweb/?p=xen.git
I've attached the current version of the patch, which needs George's
comments addressed (so we already
On 10/3/18 4:14 PM, Wei Liu wrote:
> On Thu, Sep 27, 2018 at 10:58:54AM +0300, Razvan Cojocaru wrote:
>> Currently there is a subop for setting the memaccess of a page, but not
>> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
>> functionality.
>>
On 9/19/18 3:44 PM, George Dunlap wrote:
> On 09/19/2018 01:15 PM, George Dunlap wrote:
>> On 09/03/2018 09:25 AM, Razvan Cojocaru wrote:
>>> When an new altp2m view is created very early on guest boot, the
>>> display will freeze (although the guest will run normally).
On 10/4/18 7:04 PM, Jan Beulich wrote:
On 02.10.18 at 17:17, wrote:
>> +static void ept_set_ad_sync(struct p2m_domain *hostp2m, bool value)
>> +{
>> +struct domain *d = hostp2m->domain;
>> +
>> +ASSERT(p2m_is_hostp2m(hostp2m));
>> +ASSERT(p2m_locked_by_me(hostp2m));
>> +
>> +h
On 10/4/18 7:42 PM, Wei Liu wrote:
> It is discovered that hvm_funcs made it into monitor.o even when HVM
> is disabled. This version of clang doesn't seem to completely
> eliminate the code after is_hvm_domain() in
> arch_monitor_get_capabilities().
>
> Signed-off-by: Wei
On 10/5/18 11:17 AM, Jan Beulich wrote:
On 04.10.18 at 18:40, wrote:
>> On 10/4/18 7:04 PM, Jan Beulich wrote:
>> On 02.10.18 at 17:17, wrote:
static void ept_enable_pml(struct p2m_domain *p2m)
{
+struct domain *d = p2m->domain;
+struct p2m_domain *hostp2m =
pagated, regardless of whether gla_valid is set or
> not.
>
> In particular, gla_valid will never be set on AMD systems; but
> npfec.kind will still be valid and should still be propagated.
>
> Signed-off-by: Alexandru Isaila
> Signed-off-by: George Dunlap
On 10/5/18 12:01 PM, Jan Beulich wrote:
On 05.10.18 at 10:41, wrote:
>> On 10/5/18 11:17 AM, Jan Beulich wrote:
>> On 04.10.18 at 18:40, wrote:
On 10/4/18 7:04 PM, Jan Beulich wrote:
On 02.10.18 at 17:17, wrote:
>> static void ept_enable_pml(struct p2m_domain *p2m)
>>
endor "save" hook, eliminating the need for the hook
> functions to zero individual fields.
>
> Signed-off-by: Jan Beulich
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists
On 10/4/18 7:56 PM, Tamas K Lengyel wrote:
> On Thu, Sep 27, 2018 at 1:59 AM Razvan Cojocaru
> wrote:
>>
>> Currently there is a subop for setting the memaccess of a page, but not
>> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
>> functionality.
tp2ms will inherit the hostp2m's
ept.ad value.
Signed-off-by: Razvan Cojocaru
Suggested-by: George Dunlap
---
Changes since V3:
- Removed rather uninformative last sentence of the patch
description.
- Introduced ept_{en,dis}able_hardware_log_dirty(), which take
care of locking and unlock
On 10/15/18 1:36 PM, Andrew Cooper wrote:
> Reusing debugreg[5] for the PV emulated IO breakpoint information is confusing
> to read. Instead, introduce a dr7_emul field in pv_vcpu for the pupose.
>
> With the PV emulation out of the way, debugreg[4,5] are entirely unused and
> don't need to be s
On 10/16/18 7:26 PM, George Dunlap wrote:
> On 09/27/2018 08:58 AM, Razvan Cojocaru wrote:
>> Currently there is a subop for setting the memaccess of a page, but not
>> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
>> functionality.
>>
>&g
On 10/4/18 6:20 PM, Jan Beulich wrote:
> Roger recently has posted a patch adding rangeset_merge(), which I think
> is more general than your rangeset_copy(). That said, I'm in no way
> convinced copying (and then keeping in sync) the range sets across the
> altp2m-s is the best approach. It may we
On 10/17/18 4:30 PM, Andrew Cooper wrote:
> On 17/10/18 14:26, Razvan Cojocaru wrote:
>> On 10/4/18 6:20 PM, Jan Beulich wrote:
>>> Roger recently has posted a patch adding rangeset_merge(), which I think
>>> is more general than your rangeset_copy(). That said, I'm
301 - 400 of 595 matches
Mail list logo
